Re: [exim-dev] Help debugging a tls smtp session

[Viktor Dukhovni via Exim-dev]

On Tue, Mar 28, 2023 at 01:48:25PM +0100, Andrew C Aitchison via Exim-dev wrote:

> When I do STARTTLS -> CLIENTID -> NOOP
> the CLIENTID gives the correct response code but the next command
> fails (it doesn't have to be a NOOP) in a way suggesting that I have
> lost synchronization. Sometimes the TLS connection reports unexpected
> commands in the input buffer (which I confirm to match what I expect
> the script to send next).
> 
> I do have PIPECONNECT enabled, so I may well be tangled up in that somehow.

Can you explain in more detail what the test script is doing?  Is per
chance pipelining multiple commands with STARTTLS (which then end up
in the cleartext input buffer even post STARTTLS)?

The client script must not transmit any further SMTP commands after
"STARTTLS" until it has read the response and if succesful (2XX)
completed a TLS handshake.  Only at that point may further commands be
sent, and they must be sent over the TLS connection, not the raw TCP
connection.

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2954] New: tls_eccurve (>= OpenSSL 3.0.0) dysfunctional

[Viktor Dukhovni via Exim-dev]

On Mon, Jan 02, 2023 at 03:25:17PM +, Jeremy Harris via Exim-dev wrote:

> On 02/01/2023 04:16, Viktor Dukhovni via Exim-dev wrote:
> > Mind you, things are a bit complicated with TLS 1.3, where ECDHE groups
> > and FFDHE groups are unified and always negotiated, and setting the
> > grouplist to just ECDHE groups will disable FFDHE.
> 
> Is there any particular advantage, or behaviour difference, in
> FFDHE vs. ECDHE?
>
> Is it mostly "EC keys are smaller, for equivalent protection"?

In TLS 1.3, the difference is largely performance.  It isn't only that
are FFDHE keys are larger for the same security level, but rather that
the CPU cost of the key exchange rises much faster as a function of the
effective symmetric security bits than with ECDHE.

In TLS 1.0–1.2, the story is more complex, because the FFDHE group is
not negotiated, the server just picks whatever group it sees fit.  This
choice could have a security benefit (resist precomputation attacks if
each server is configured with a locally generated strong set of DH
parameters), or it could be weak (1024-bit), or needlessly slow (8192
bit), or perhaps even some form of MITM downgrade attack (a small
subgroup attack that somehow works, though server signatures over the
key exchange parameters are expected to prevent this).

This is why there is an active thread on the TLS WG list about
deprecating FFDHE in TLS 1.2.  (IMHO there is a better path forward,
to make ECDHE MTI, and preferred when mutually available, ... raise
the ceiling, not the floor, but I'm likely in the minority along
with the usual suspects like Peter Gutmann).

Anyway, in TLS 1.3, FFDHE groups are negotiated, just like the ECDHE/ECX
groups, so performance is the only consideration, but FFDHE is there as
a fallback in case we need to urgently drop support for the EC
algorithms, or some peer (client or server) does not support ECDHE/ECX
for some reason.  [ ECX here means X25519 or X448. ]

For Postfix, I'll probably need to add a second configuration parameter
for the FFDHE groups, and when OpenSSL is 3.0 or later, ask OpenSSL
to enable the union of the two lists.

In Exim, the set of supported EC/ECX curves should not be a singleton.
Interoperability considerations strongly suggest that both clients and
servers should support a range of curves, at least one of which (say
P-256 and perhaps also X25519, making two) is MTI.

Similarly, for FFDHE, the set of supported groups (if any are supported)
should include at least ffdhe2048 and ffdhe3072.  My personal take is
that 4096-bit RSA and FFDHE are too slow to be useful, if you want that
security level use EC.  Enable 4096-bit RSA and FFDHE only if EC fails,
but FFDHE survives and 4096-bit RSA/FFDHE is all that's available.

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2954] New: tls_eccurve (>= OpenSSL 3.0.0) dysfunctional

[Viktor Dukhovni via Exim-dev]

On Sun, Jan 01, 2023 at 05:48:50AM +, admin--- via Exim-dev wrote:

> It is impossible to set a custom tls_eccurve if Exim is compiled against
> OpenSSL >= 3.0.0 due to a parenthesis error: The value of SSL_CTX_set1_groups
> rather than the comparison against 0 is assigned to rv, which subsequently
> fails at "return !rv;"
> 
>   https://github.com/Exim/exim/pull/89

For the record, in case anyone is reading this here and not just on the
bug tracker, nobody should be setting an explicit custom EC curve.  The
interoperable setting is to enable curve negotiation, either with the
default set of curves (requires no code), or an explicit list:


https://github.com/vdukhovni/postfix/blob/master/postfix/src/global/mail_params.h#L3345-L3376

https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_server.c#L670

https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_dh.c#L303-L372

Where the above is just setup machinery for calling SSL_CTX_set1_curves()
with the desired list of curve ids:


https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_dh.c#L365

The relevant OpenSSL documentation is at:

https://www.openssl.org/docs/man3.0/man3/SSL_CTX_set1_curves.html

Mind you, things are a bit complicated with TLS 1.3, where ECDHE groups
and FFDHE groups are unified and always negotiated, and setting the
grouplist to just ECDHE groups will disable FFDHE.

This also means, now that I think about it, that the quoted Postfix code
perhaps needs a tweak to not inadvertently disable the TLS 1.3 FFDHE
groups (unless that's a feature).

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2911] New: setting dns_again_means_nonexist to a list containing @mx_ lookups causes segfault

[Viktor Dukhovni via Exim-dev]

On Fri, Aug 19, 2022 at 02:04:06PM +, admin--- via Exim-dev wrote:

> https://bugs.exim.org/show_bug.cgi?id=2911
> 
> Bug ID: 2911
>Summary: setting dns_again_means_nonexist to a list containing
> @mx_ lookups causes segfault
>Product: Exim
>Version: 4.96
>   Hardware: x86
> OS: Linux
> Status: NEW
>   Severity: bug
>   Priority: medium
>  Component: List matching
>   Assignee: unalloca...@exim.org
>   Reporter: thomasm-e...@wupper.com
> CC: exim-dev@exim.org
> 
> Now if a DNS lookup for a MX gives TRY_AGAIN, exim will check whether the name
> MX name is in dns_again_means_nonexist. [...]

Note that if this also potentially applies to TLSA lookups, then
downgrading SRVFAIL (try again) to NXDOMAIN breaks the downgrade
resistance of DANE.

This is of course also likely to trigger bounces in the presence of
transient errors, and is basically a really bad idea.

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 1895] Default groups for DH possibly backdoored

[Viktor Dukhovni via Exim-dev]

On Sun, Apr 07, 2019 at 07:25:38PM +, admin--- via Exim-dev wrote:

> > If so, assuming the p for a parameter has been chosen as a "safe prime",
> > q is entirely dependent on p - which we have from the PEM representation.
> > Why do we care about loading q?
> 
> FWIW: I have no idea.  I almost knew, once, when Viktor explained it before. 
> This again is part of why I try to stick to using crypto-engineering, not
> crypto policy, and defer to experts.

There are two common representations of FFDHE groups:

* (p, g) with just the modulus p and a generator g of a suitable
  subgroup of the non-zero residues mod p under multiplication.

* (p, g, q) with the modulus p, a generator g of a suitable
  subgroup of the non-zero residues mod p under multiplication,
  and the order (element count) of the subgroup generated by g.

The equivalent symmetric strength depends on p with brute-force attacks
roughly as difficult as for RSA keys of the same size, and also on q,
with attack cost of half the bit count of q.

Thus, e.g. for 80-bit security (now passé), you'd go with a 1024-bit
modulus and a generator of a subgroup with 2^160 elements.

Because exponents can be reduced mod q, computations are faster in (p,
g, q) groups when q is chosen much smaller than p, to match the
symmetric strength of the construction.

With "safe" primes, there is indeed no point in specifying q, unless
the library or protocol wants to work with (p, g, q).  With "safe"
primes there are no small subgroups other than {1, -1}.  With (p, g, q)
one can check that q is prime and that the order of g is q, and then
be sure to not be at risk of small subgroup issues.

These days, the trend is to use ECDHE, but when using FFDHE, to use
one of the RFC7919 groups.

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2816] Repeated deliveries to yahoo.co.jp

[Viktor Dukhovni via Exim-dev]

On Fri, Oct 22, 2021 at 10:34:20PM +0100, Simon Arlott via Exim-dev wrote:

> It is likely that pipelining the QUIT results in the connection being
> closed with outgoing data discarded. It's entirely possible that a
> stateful firewall decides not to allow the half-closed connection to
> transfer the remaining data.

Possible, and perhaps on the sender's end rather than at Yahoo?  FWIW,
Postfix also pipelines QUIT, and I don't recall seeing similar reports
on postfix-users.

> A packet capture of this issue would be useful.

Yes, definitely.

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2816] Repeated deliveries to yahoo.co.jp

[Viktor Dukhovni via Exim-dev]

On Fri, Oct 22, 2021 at 08:17:03PM -, Jasen Betts via Exim-dev wrote:

> >> If this is really an exim bug, it's still worth correcting it, but you 
> >> should
> >> really disable pipelining to yahoo, even when this bug will be resolved.
> >
> > Why would they bother advertising PIPELINING, if they don't
> > actually mean to tolerate its use?  That does not seem right...
> >
> 
> BINARYMIME
> RFC3030 (https://datatracker.ietf.org/doc/html/rfc3030#section-4.2)
> doesn't show pipelined BDAT: the sender synchronises before sending
> body data.  Dropping the connection seems like a resonable response
> to such a synchronisation error.
> 
> PIPELINING
> RFC2920 (https://datatracker.ietf.org/doc/html/rfc2920)
> synchrionises the pipeline before any message content is trasmitted
> (the "DATA" command is allowed but the sender must wait for "354" 
> before sending content)

The yahoo.co.jp domain advertises only PIPELINING not CHUNKING or
BINARYMIME:

< 250-mtagw7025.mail.djm.ynwp.yahoo.co.jp
< 250-PIPELINING
< 250-8BITMIME
< 250 SIZE 2048

If they wanted to punish senders for *using* it, WTF advertise it?

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2816] Repeated deliveries to yahoo.co.jp

[Viktor Dukhovni via Exim-dev]

> On 22 Oct 2021, at 11:45 am, admin--- via Exim-dev  wrote:
> 
> For what it's worth, by experience, you should avoid sending anything to any
> yahoo domains using pipelining. They will just retaliate on you if you do it,
> they will, for example, greylist the servers using pipelining but will allow
> the other ones.
> If this is really an exim bug, it's still worth correcting it, but you should
> really disable pipelining to yahoo, even when this bug will be resolved.

Why would they bother advertising PIPELINING, if they don't
actually mean to tolerate its use?  That does not seem right...

-- 
Viktor.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2822] Issues with DHE ciphers - problems with GnuTLS implementation?

[Viktor Dukhovni via Exim-dev]

On Wed, Oct 20, 2021 at 12:00:17AM +, admin--- via Exim-dev wrote:

> The 4th shows that on 2000+ connections in the logs nothing is actually using 
> a
> DHE cipher suite either. Which makes a bug on the sslscan unlikely - esp. 
> since
> it works as expected against gnutls-serv with the same string.

Typically, even with DHE enabled, the selected cipher would use ECDHE
when both sides support it, also, depending on what is logged with TLS
1.3, the key exchange group may not even be logged, and TLS 1.3 cipher
names onlly describe the symmetric crypto.

Indeed neither exim.org nor Phil Pennock's domain seem to support DHE,
but Heiko's Exim server does, at least when client offers only TLSv1.2
with just DHE ciphers.  Don't know whether it uses GnuTLS or OpenSSL:

< 220 mx10.schlittermann.de ESMTP Exim 4.95 Wed, 20 Oct 2021 00:30:55 +0200
> EHLO ...
< 250-mx10.schlittermann.de ...
< ...
< 250-STARTTLS
< 250 HELP
> STARTTLS
< 220 TLS go ahead
mx10.schlittermann.de[46.38.236.101]:25: Matched DANE EE ...
Verified TLS connection established to 
mx10.schlittermann.de[46.38.236.101]:25: TLSv1.2 with cipher 
DHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Similarly, Jeremy's MX host also supports DHE ciphers:

< 220-w81.wizint.net ESMTP Exim 4.94.133 Tue, 19 Oct 2021 22:40:50 +
Untrusted TLS connection established to 
wizmail.org[2a00:1940:107::2:0:0]:25: TLSv1.2 with cipher 
DHE-RSA-AES256-GCM-SHA384 (256/256 bits)

> Then there is some reasoning why this is important for us at least.

Or only seemingly important, as I noted earlier.

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2822] Issues with DHE ciphers - problems with GnuTLS implementation?

[Viktor Dukhovni via Exim-dev]

On Tue, Oct 19, 2021 at 09:21:24PM +, admin--- via Exim-dev wrote:
> https://bugs.exim.org/show_bug.cgi?id=2822
> 
> --- Comment #2 from Jeremy Harris  ---
> a) you didn't say what version of GnuTLS, nor distribution of Exim
> b) working out what you are trying to say in that wall of text is tiring

Though my comment likely won't make it into the ticket log, and so might
not reach the OP, I feel obliged to note that turning up TLS security to
11 for opportuistic TLS in SMTP is rather a bad idea.

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

Unless such settings are limited to the submission ports, the net result
of raising the floor that high, would be more email transmisison in the
clear, which rather defeats the purpose (presumably greater SMTP
security).

If e.g. ~112 bit security (2048-bit DHE) is sufficient to protect most
of the web, most software update servers, ...  surely it should be good
enough for opportunistic TLS in SMTP.

I realise that my admonitions are unlikely to make a big dent in the
popularity of roasting one's crypto on "HIGH", but perhaps there are one
or two rational folks I might persuade to consider a more realistic
threat model.

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] DANE library for Exim + OpenSSL and upcoming OpenSSL 3.0.0 release.

[Viktor Dukhovni via Exim-dev]

On 12 Aug 2021, at 5:05 pm, Jeremy Harris via Exim-dev  
wrote:

> > Perhaps you mean OpenBSD,  FreeBSD 12 dropped LibreSSL and went back to
> > OpenSSL.
> 
> Nope.  There's a buildfarm animal listed as "FreeBSD latest"
> showing as building with LibreSSL 3.3.3

Well, sure, LibreSSL is available in ports, but the base system has
returned to OpenSSL:

  $ uname -sr
  FreeBSD 12.2-RELEASE-p3

  $ /usr/bin/openssl version -a
  OpenSSL 1.1.1h-freebsd  22 Sep 2020
  built on: reproducible build, date unspecified
  platform: FreeBSD-amd64
  options:  bn(64,64) rc4(16x,int) des(int) idea(int) blowfish(ptr) 
  compiler: clang
  OPENSSLDIR: "/etc/ssl"
  ENGINESDIR: "/usr/lib/engines"
  Seeding source: os-specific

There is also an OpenSSL in ports:

$ pkg info openssl| head
openssl-1.1.1k,1
Name   : openssl
Version: 1.1.1k,1
Installed on   : Fri Mar 26 11:54:30 2021 EDT
Origin : security/openssl
Architecture   : FreeBSD:12:amd64
Prefix : /usr/local
Categories : security devel
Licenses   : OpenSSL
Maintainer : br...@freebsd.org

If some user is building with LibreSSL, that's their choice, but the
Exim project is surely not obligated to indulge them forever if
maintaining three TLS backends is too much effort.

There's nothing compelling about Exim + LibreSSL vs. Exim + OpenSSL
at this point in time.

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] DANE library for Exim + OpenSSL and upcoming OpenSSL 3.0.0 release.

[Viktor Dukhovni via Exim-dev]

On Thu, Aug 12, 2021 at 08:59:54PM +0100, Jeremy Harris via Exim-dev wrote:

> On 12/08/2021 15:30, Viktor Dukhovni via Exim-dev wrote:
> > You'd be able to drop the "danessl" library.
> 
> You mean, the three source files.  No library involved.

Yes, the copy of the library imported into Exim.

> > then let it do all the work.
> 
> And lose the observability we currently have.  I bet the library
> implementations don't expose that.

I wrote the built-in DANE support in OpenSSL, it provides some
introspection hooks you can call at the conclusion of the handshake
to report on whether DANE happened, and how the peer was matched.

Postfix did not lose any substantive observability when moving
to the OpenSSL built-in DANE support.

> > No, there's no DANE support in LibreSSL.  My advice would be to drop
> > LibreSSL support.
> 
> Can't; the FreeBSD guys like it.

Perhaps you mean OpenBSD,  FreeBSD 12 dropped LibreSSL and went back to
OpenSSL.  My home server is FreeBSD.

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] DANE library for Exim + OpenSSL and upcoming OpenSSL 3.0.0 release.

[Viktor Dukhovni via Exim-dev]

On Thu, Aug 12, 2021 at 09:51:53AM +0100, Jeremy Harris via Exim-dev wrote:

> > With OpenSSL 1.0.2 long EOL, is there any chance that newer versions
> > of Exim could set the floor OpenSSL version to 1.1.1 and migrate to
> > use the built-in DANE support?  I'd can offer some help to get you
> > there, and then retire the standalone library for good...
> 
> I tried (rather briefly) to reactivate my openssl build environmentm
> so as to see what works and doesn't under the current nearly-3.0.0
> OpenSSL.  But it seems to be bust, and it's one of those things that
> is far too convoluted to work on.

FWIW, provided one is willing to ignore some deprecation warnings,
Postfix builds with 3.0.0, with just one change to constify an EC_KEY
object, used to access curve metadata for logging.  The patch to deal
with deprecations is somewhat more invasive, but not too bad, just had
to rewrite the DH parameter loading.

> I'm quite expecting Exim to start breaking horribly, when 3.0.0
> appears on real systems.

Yes, there's a non-trivial chance it may not compile without some
changes.  More mundane applications are expected to not have issues,
but Exim has the low-level code for DANE, and perhaps other tweaks
that make it much less of a vanilla OpenSSL application.

> I've occasionally considered working on a move to the native DANE
> support, under both OpenSSL and GnuTLS (which we officially support).
> But I expect it to be a whole bunch of work, and invasive to the point
> of horribly complexifying the Exim codebase.

You'd be able to drop the "danessl" library.  The native DANE support is
fairly simple to use.  Just tell the OpenSSL library the TLSA base
domain (effective SNI and hostname for namechecks) and which TLSA
records to use and then let it do all the work.

> (Likewise, so will fixing whatever 3.0.0 breaks for us, since we
> cannot drop support for earlier versions.)

My Postfix snapshot supports both 1.1.1 and 3.0.0.  We dropped 1.0.2
support in Postfix 3.6 released in April, and skipped 1.1.0 (not a
stable release and no longer supported).

> You might guess that my enthusiasm is rather low, here.

Sure, but it probably just needs to get done...  I can help with
suggested code snippets to replace things that no longer work as you run
into them.

> The there's the LibreSSL question.  I've never found any decent docs
> for it; we only discover issue where it differs from OpenSSL
> one-at-a-time.  Currently we manage this with a raft of feature-macros
> just like we have to for OpenSSL versions.  Do you know if LibreSSL
> has the same DANE APIs as OpenSSL?

No, there's no DANE support in LibreSSL.  My advice would be to drop
LibreSSL support.  But if you stick with LibreSSL (1.0.2 on life support
forever), then by now it needs to become a completely separate TLS
support module just like GnuTLS.  The list of differences is growing
to a point that conditional compilation macros would make the code too
difficult to understand/maintain.

> As far as dropping support for earlier OpenSSL versions goes: there is
> at least one system in the buildfarm not operated by me and running
> with OpenSSL 1.0.1s - a Solaris 10.  I assume that means there is at
> least one person out there still interested in operating Exim on
> systems of that vintage, even though the OpenSSL project calls it End
> Of Life.

Sure, but at some point that person would have to settle for running
vintage Exim as well.  There are no longer any public releases of
bug fixes for 1.0.2, it is a dead branch (IIRC since Dec 2019).

At some point it is time to move on...

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] DANE library for Exim + OpenSSL and upcoming OpenSSL 3.0.0 release.

[Viktor Dukhovni via Exim-dev]

The upcoming OpenSSL 3.0.0 release is now in beta and should ship some time in 
the next few months.
This brings some low level changes to the library, that don't affect most 
applications, but may require
changes in the legacy standalone DANE library I wrote for OpenSSL 1.0.0+.

While the changes look largely manageable, I'd rather not continue to maintain 
the legacy
DANE library in perpetuity, given that OpenSSL 1.1.0 and later have built-in 
DANE support.

With OpenSSL 1.0.2 long EOL, is there any chance that newer versions of Exim 
could set the
floor OpenSSL version to 1.1.1 and migrate to use the built-in DANE support?  
I'd can offer
some help to get you there, and then retire the standalone library for good...

-- 
Viktor.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2730] New: EAI trace information doesn't log domains as U-labels

[Viktor Dukhovni via Exim-dev]

> On May 4, 2021, at 8:47 PM, John R. Levine via Exim-dev  
> wrote:
> 
>>> https://bugs.exim.org/show_bug.cgi?id=2730
> 
>> It seems you're referring to:
>> 
>> https://tools.ietf.org/html/rfc6531#section-3.7.3
>> 
>>  When an SMTPUTF8-aware SMTP server adds a trace field to a message
>>  that was or will be transmitted with the SMTPUTF8 parameter included
>>  in the MAIL commands, that server SHOULD use the U-label form for
>>  internationalized domain names in the new trace field.
>> 
>> Which appears to be concerned primarily with the "Return-Path:" header,
> 
> No, what I was testing was the domain names in Received headers, the FROM and 
> BY clauses.  Discussions in the IETF have told us that it is a religious 
> issue whether you consider Return-Path to be a trace field.

I see, but the domains in question are:

   * "from": The EHLO name sent by the peer before SMTPUTF8 is announced,
 So necessarily ASCII.
   * "by":   The receiving system name announced in the SMTP greeting also
 before SMTPUTF8 is announced, so again necessarily ASCII.
 
If the specification in 3.7.3 expects these to be transformed to Unicode
in the trace headers even though they're sent and received as A-labels
in the actual SMTP dialogue, then I am not impressed by the specification.

>> In that context, use of non-ASCII domain forms may needlessly break
>> message delivery, if the mailstore does not support non-ASCII headers,
>> and UTF8 would not otherwise appear in the message headers.
> 
> If UTF8 would not otherwise appear in the message headers, why would the mail 
> be sent as SMTPUTF8?

It needs to be declared SMTPUTF8 when any of the envelope addresses are UTF8.
If those are Bcc addresses, or the headers have been rewritten to no longer
use UTF8, then the message content may be free of UTF8, leaving UTF8 in just
the (at least incoming) envelope.

> That doesn't strike me as a very strong argument.
> 
> Like I said, it's not a huge bug, but the spec is clear enough.

The spec is clear, but likely misguided, just like the 552 -> 452
downgrade in 5321, which nobody implements, because it is misguided.

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2730] New: EAI trace information doesn't log domains as U-labels

[Viktor Dukhovni via Exim-dev]

> On May 4, 2021, at 2:48 PM, admin--- via Exim-dev  wrote:
> 
> https://bugs.exim.org/show_bug.cgi?id=2730
> 
> 
> RFC 6531 says you SHOULD do this.  In IETF-ese "SHOULD" means MUST unless 
> there
> is a compelling technical reason not to do it, not do this if you feel like 
> it.
> (That's MAY.)
> 
> It's not a huge bug but it looks easy to fix.

It seems you're referring to:

  https://tools.ietf.org/html/rfc6531#section-3.7.3

   When an SMTPUTF8-aware SMTP server adds a trace field to a message
   that was or will be transmitted with the SMTPUTF8 parameter included
   in the MAIL commands, that server SHOULD use the U-label form for
   internationalized domain names in the new trace field.

Which appears to be concerned primarily with the "Return-Path:" header,
which is only added on *final* delivery to a mailbox (possibly via
LMTP).

In that context, use of non-ASCII domain forms may needlessly break
message delivery, if the mailstore does not support non-ASCII headers,
and UTF8 would not otherwise appear in the message headers.

Also "Return-Paths" in UTF8 form would rather hinder abuse reporting,
or other help from postmasters, ... when the script in question is
foreign to the mail system operators.  Users, on the other hand, rarely
look at trace headers...

Thus section 3.7.3 of the RFC looks misguided to me, I would would be
tempted to ignore it with prejudice.

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2594] CNAME handling can break TLS certificate verification

[Viktor Dukhovni via Exim-dev]

> On Mar 15, 2021, at 6:24 AM, Heiko Schlittermann via Exim-dev 
>  wrote:
> 
> If the next hop's hostname comes from insecure DNS, you're right. If the
> next hop's hostname is hard-wired into the configuration (as typically
> found in "use-a-smarthost" setups), I believe, it's useful to check the
> next hop's certificate prior sending credentials or other private data.

Yes, in the absence of MX lookups, the nexthop host is securely
known, and can be validated.  This is in fact typical for submission,
where MX lookups don't apply.

Thus a locally configured nexthop of [smtp.example.net]:587 can and should
be subject to TLS certificate checks, and not subjected to CNAME expansion,
unless somebody also has DANE for port 587 (and TLSA records on the far end
of an end-to-end signed CNAME chain).

-- 
Viktor.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2594] CNAME handling can break TLS certificate verification

[Viktor Dukhovni via Exim-dev]

For the record, the expectation is:

 - Absent DANE TLSA records, the literal MX hostname, which is
   of course insecurely obtained from MX records, so validation
   is mostly an exercise in futility.  It would only mean something
   if MTA-STS were implemented, but Exim does not MTA-STS last I
   heard.

 - If DANE TLSA records are found at some "TLSA base domain"
   (which is either the securely CNAME expanded MX host, or else
   the original MX host from the signed MX RRset), then that's
   the name to use in SNI and check in the certificate when validating
   "2 X X" TLSA records).

> On Mar 13, 2021, at 8:56 AM, admin--- via Exim-dev  wrote:
> 
> Checked in real-world and it seems to work as expected. The router sets the
> host to smtp.office365.com, DNS CNAMES redirect to a bunch of other names 
> which
> in turn resolve to addresses.
> 
> The certificate the peers present match the hostname of the router and Exim
> now can verify that.

-- 
Viktor.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2704] DANE client-side documentation issues

[Viktor Dukhovni via Exim-dev]

On Sat, Mar 06, 2021 at 11:04:57PM +, admin--- via Exim-dev wrote:

> https://bugs.exim.org/show_bug.cgi?id=2704
> 
> --- Comment #5 from Simon Arlott  ---
> I'd want to do DANE for all hosts that are DNSSEC signed but not require it
> otherwise.

This makes no sense.  On what basis would you expect to have TLSA
records for all MX hosts in DNSSEC-signed zones?

> There doesn't appear to be a way to require DANE if there's a signed TLSA
> result without also refusing connections when the host lookup is not signed.

You appear to be confused.  DANE is *required* when there are signed
DANE TLSA records.

> I'd expect that if the host lookup is signed, the TLSA result must be signed
> (either present or not present) and then strictly followed.

That's not always true.  Some zones have "insecure" denial of existence
via NSEC3 opt-out.  Also, the TLSA qname could be a CNAME (perhaps
wildcard synthesised) into an unsigned zone.

> As described above, "hosts_try_dane = *" is insecure if the TLSA
> result is unsigned.

If there are no signed TLSA records, then DANE is not enforced.  That's
correct.  There's not much point in honouring unsigned TLSA records,
they're supposed to defend against *active* attacks.  For passive
monitoring, just STARTTLS is enough.  Active on-path attackers can just
return forged TLSA replies matching the certs of their MiTM stack.

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2704] DANE client-side documentation issues

[Viktor Dukhovni via Exim-dev]

On Sun, Feb 28, 2021 at 07:04:58AM +, admin--- via Exim-dev wrote:

> This quoting was too selective. - Could you please post a corrected
> clomplete pseudocode? I cannot specify exactly what is wrong/unclear
> with the documentation (and come up with a patch) unless I have an
> understanding of what exim actually does.

Regardless of what it does, in order to be a correct implementation
of DANE it SHOULD:

- When DANE is opportunistic (not apriori mandated by local
  policy for some set of destinations that MUST have DANE
  TLSA records):

- Check that the destination domain has DNSSEC-signed MX
  records.  If not, continue with normal opportunstic TLS.

- Check that the current MX host is in a DNSSEC-signed zone.
  (Its A/ records are signed or result from a CNAME
  chain whose first "link" is DNSSEC signed).
  If not, continue with normal opportunstic TLS.

- If the MX A/ records are an end-to-end signed CNAME
  chain (all links signed), then look for TLSA RRs first
  at the end of the chain.  If no TLSA records found there,
  or if not a chain or chain not signed end-to-end, look
  for TLSA RRs at the original MX name.

  When looking for TLSA RRs, prepend _._tcp to the
  candidate "TLSA base domain", and check the status of
  the answer:

* If signed TLSA RRs found (AD=1), bingo, use these.
* If NODATA or NXDOMAIN (secure or insecure), fine,
  no TLSA records for this candidate base domain.
* If insecure answer, likewise.
* Any query status other than answers, NODATA, or
  NXDOMAIN is a hard error for the MX host in question.
  Continuing to use the MX host would open up downgrade
  attacks.

- If no signed TLSA RRs found, continue with normal
  opportunistic TLS.

- Otherwise, use the obtained TLSA records to require that
  the MX host provides STARTTLS and refuse to downgrade to
  cleartext.

- If any of the TLSA records are "usable", require that the
  presented certificate chain validates against these TLSA
  records.  Most sensible server operators avoid all TLSA
  usages other than "3 1 1" and "2 1 1", but the client
  should be willing to validate any "2 [01] [012]" or
  "3 [01] [012]" record.  On authentication failure, terminate
  the connection without delivering mail.

  With "2 X [12]" records, the issuing CA certificate MUST be
  included in the server's certificate chain message.

- If none of the TLSA records are usable, just enforce STARTTLS,
  without authentication.

- When DANE is mandated by local policy, do all the above, but
  never fallback to cleartext or unauthenticated TLS.  Instead
  just skip the MX host if signed TLSA records that authenticate
  the remote chain are not available.

> | A TLSA lookup will be done if either of the above options match and the
> | host-lookup succeeded using DNSSEC.  If a TLSA lookup is done and
> | succeeds, a DANE-verified TLS connection will be required for the host.
> | If it does not, the host will not be used; there is no fallback to
> | non-DANE or non-TLS.
> 
> Which translates to
> if ( (hosts_require_dane OR hosts_try_dane)
>  AND successful DNSSEC host-lookup) {
>check for TLSA record
>if there is a TLSA record
>   require DANE-verified TLS connection
>else /* reading "If it does not" as "no TLSA found" */
>   skip host

There is in the text you quote a failure to distinguish between two
types of "success":

   A. The query did not fail, returning an answer, NODATA, or
  NXDOMAIN.

   B. The query returned a DNSSEC-validated non-empty answer.

If "A" fails, the host MUST be skipped, no fallback, ...  If only "B"
fails, then unless DANE is *required*, the MX host should be used
with normal opportunstic TLS.

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2702] New: XCLIENT ESMTP extension

[Viktor Dukhovni via Exim-dev]

> On Feb 22, 2021, at 12:23 PM, admin--- via Exim-dev  wrote:
> 
> - Proper handling of the proxy address/port details, for logging
> - We should consider re-calling the connect ACL, after deciding to accept the
>  XCLIENT command, to give the chance to re-evaluate connect-time decisions
>  with the proxy-supplied info for the connection

I'd put it more strongly than *consider*, the purpose of XCLIENT is 
*specifically*
to reevaluate ACLs, so that the proxy acts on behalf of its upstream client.  If
one merely wants an audit trail, that'd be the XFORWARD extension instead.

> - Ditto re-call the helo ACL, with the HELO attribute value
> - We could consider a dedicated ACL for the command, separate from the
>  allowed-hosts list (still needed for advertise)

Yes, highly recommended.  Giving all hosts allowed to relay the right to
impersonate other hosts is surely too liberal.  Also make sure that the
the right to send XCLIENT again is not retained once the initial XCLIENT
command happens (or is at least reevaluated per the upstream IP address,
which would generally not have that right).

-- 
Viktor.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] Default received_headers_max should be increased dramatically

[Viktor Dukhovni via Exim-dev]

On Wed, Dec 02, 2020 at 12:57:18AM -0500, Phil Pennock via Exim-dev wrote:

> I myself have only ever seen 30 reached when there's been a loop, but
> raising the default to 100 is reasonable IMO.
> 
> Anyone object?  Basis for objection?  If objecting, alternative
> proposal?

FWIW, Postfix defaults to 50 hops.  If Exim raises its limit to 100,
it'll run into bounces from any downstream Postfix systems.  So before
jumping to 100, perhaps a more moderate 50 might be enough.  I haven't
seen any complaints about 50.

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

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2265] TLS SNI not auto-set for DANE clients

[Viktor Dukhovni via Exim-dev]

> On Aug 17, 2020, at 7:08 PM, admin--- via Exim-dev  wrote:
> 
> https://bugs.exim.org/show_bug.cgi?id=2265
> 
> --- Comment #8 from Jeremy Harris  ---
> Disabling multi_domain turns out to be Extremely Painful because we don't find
> out
> that DANE was used until deep in the transport, well after the addresslist was
> built for a message - combined with all the ways Exim tries to re-use a
> connection for multiple messages.  I can see it being a fertile source of 
> bugs.

FWIW, yes connection and TLS session reuse are tricky in the context of 
potentially
different security policies for different destinations.  This is a source of 
some
non-trivial complexity in the Postfix SMTP client.

The session and connection caches have multi-element lookup keys (run through
SHA256 in the case of the session cache) that combine some of the following
(partial list):

- transport (router) name
- nexthop domain
- TLS security level
- SNI name
- Remote IP address
- Remote name from first line ("250-") of EHLO
- DANE TLSA RRset
- TLS reference identifiers (names to check in the cert)
- ...

This took quite time and effort to build, and there are dedicated
functions for constructing the lookup keys for saving and retrieving
live connections and cached TLS sessions.

The Exim case should be somewhat simpler since nothing is persisted
out of process, but also trickier, because you're trying to collect
multiple messages to send down the connection in real time, rather
than squirreling away the connection for potential reuse by another
separate delivery.

I don't know anything about the internals of multi-domain support
in Exim, but can see that this could be a pain.  And yet, it is
largely an unavoidable issue.  The security constraints do mean
that some messages that would otherwise be grouped for transmission
over a single channel, can no longer be correctly grouped that way.


-- 
Viktor.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2624] When using manualroute TLS certification is not safe

[Viktor Dukhovni via Exim-dev]

On Fri, Jul 17, 2020 at 07:26:20PM +, admin--- via Exim-dev wrote:

> https://bugs.exim.org/show_bug.cgi?id=2624

Isn't this a duplicate of

https://bugs.exim.org/show_bug.cgi?id=2594

> > Exim's manualroute should not replace the secure user provided hostname with
> > anything else.
> 
> Cite standards, please.  Otherwise, you are saying that CNAME should not be
> followed for manualroute, and it isn't clear why.

With the expected behaviour already settled in the earlier bug report?

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] DANE support in Exim with OpenSSL

[Viktor Dukhovni via Exim-dev]

On Wed, Jul 08, 2020 at 06:54:14PM -0400, Phil Pennock wrote:

> On 2020-07-06 at 01:07 -0400, Viktor Dukhovni via Exim-dev wrote:
> > I would like recommend that when convenient, Exim should probably do the
> > same.  The documentation for the OpenSSL DANE API is at:
> 
> LibreSSL.

I take this rather terse reply to mean that the OpenSSL code in Exim is
intended to be agnostic between OpenSSL and LibreSSL.  If that's the
case, then indeed you're stuck until that changes, or LibreSSL adds
API-compatible DANE support (I would guess unlikely to happen soon).

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] DANE support in Exim with OpenSSL

[Viktor Dukhovni via Exim-dev]

openSSL 1.0.2 has passed EOL, and 1.1.1 is the primary LTS (indeed
presently only one still supported) OpenSSL release, and OpenSSL 3.0
soon to enter beta.

With that in mind, in Postfix I decided to replace the legacy DANE code
(essentially the same as, and the original version of what is presently
used in Exim) with new DANE code that delegates all the X.509 validation
logic to OpenSSL, and just marshals the TLSA records into OpenSSL for
validation.

I would like recommend that when convenient, Exim should probably do the
same.  The documentation for the OpenSSL DANE API is at:

https://www.openssl.org/docs/man1.1.0/man3/SSL_CTX_dane_enable.html

If you have questions about the OpenSSL DANE API, feel free to drop me
a note, or ask on this list.  This does not subsume the DNS logic, so
Exim would still need to perform all the relevant lookups and decide
when enable DANE etc., but all the chain verification logic would now
be via OpenSSL, rather than my legacy danssl library (still found at:
https://github.com/vdukhovni/ssl_dane).

The new Postfix DANE code will appear in an upcoming Postfix 3.6
snapshot, for eventual inclusion in the 3.6 stable release in early
2021.

[ Because Postfix uses DANE also for its "fingerprint" security policy,
and for per-destination trust-anchors mapping these to synthetic DANE-EE
and DANE-TA records as appropriate, the code in Postfix is probably not
the best reference implementation to look at, many other things going
on besides just DANE.  The OpenSSL docs should be sufficient, but if I
not I'll be happy to fill any gaps that need attention. ]

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2594] CNAME handling can break TLS certificate verification

[Viktor Dukhovni via Exim-dev]

On Tue, Jun 09, 2020 at 04:41:33PM +0100, Jeremy Harris via Exim-dev wrote:

> On 08/06/2020 14:51, Viktor Dukhovni via Exim-dev wrote:

> > Yes:  https://tools.ietf.org/html/rfc6125#appendix-B.4
> > 
> > The original reported is right.
> 
> No, it's worse.  If you take that RFC 3207 wording strictly:
> 
>   -  A SMTP client would probably only want to authenticate an SMTP
>   server whose server certificate has a domain name that is the
>   domain name that the client thought it was connecting to.
> 
> it could mean the domain part of the recipient email address,
> pre-MX-lookup.  Thanks to the word "domain".
> 
> Or it could mean that, again, but only when there is no MX record
> and an A /  is being used... but pre-CNAME.
> 
> Or it could mean post-CNAME, because that "client" SMTP agent surely
> thought it was connecting to a name that A/ resolved to the IP for
> the connect() syscall.
> 
> 
> It really is not well specified.

Perhaps so, but in the context of everything else in RFC6125, and the
specs for other protocols, ... it is fairly clear (to me anyway) that
the intent is to match the SMTP server name prior to CNAME expansion,
just like the HTTP/IMAP/... cases.

This is also, FWIW, what's expected with MTA-STS.

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2594] CNAME handling can break TLS certificate verification

[Viktor Dukhovni via Exim-dev]

On Mon, Jun 08, 2020 at 12:48:22PM +, admin--- via Exim-dev wrote:

> https://bugs.exim.org/show_bug.cgi?id=2594
> 
> --- Comment #1 from Jeremy Harris  ---
> Can you locate a standards document specifying the name that should be checked
> against the certificate?

Yes:  https://tools.ietf.org/html/rfc6125#appendix-B.4

The original reported is right.  Aside from DANE, the correct name to
check in the certificate is the original name, not the (generally
insecure) CNAME expansion.

With DANE SMTP (RFC7672) CNAMEs can *augment* the set of valid names to
check in the certificate, to include the name associated with the TLSA
base domain, which might be a fully-expanded CNAME, provided the
expansion never strayed into a DNSSEC-unsigned zone.

https://tools.ietf.org/html/rfc7672#section-3.2.2

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2298] tls_eccurve does not accept multiple entries

[Viktor Dukhovni via Exim-dev]

On Sun, Sep 29, 2019 at 07:22:46PM +, admin--- via Exim-dev wrote:

> > I'm so far unconvinced that your use-case, for more-than-one but not the 
> > full
> > set, is likely to be needed by enough people to be worth adding the support.
> 
> Well, it can be very convenient to manually add a modern curve as first choice
> and add less modern curves for compatibility reasons.

Specifying your own non-default (not "auto") curve list is more
often for "incompatibility" reasons.  For the vast majority of users
the default is fine, and curating bespoke combinations rarely enhances
security.

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 1895] Default groups for DH possibly backdoored

[Viktor Dukhovni via Exim-dev]

On Tue, Mar 19, 2019 at 07:37:37AM +, Andrew C Aitchison via Exim-dev wrote:

> > FWIW, Postfix 3.4, released a few weeks ago no longer supports OpenSSL 
> > versions prior to 1.0.2.
> 
> Not sure from that whether Postfix 3.4 supports OpenSSL 1.0.2 ?

It supports 1.1.x, 1.0.2, and nothing earlier.  Older OpenSSL
releases are still supported with Postfix 3.1, 3.2 and 3.3.

My posts are basically lending support to the idea that this may
be a good time for *new* Exim releases to require OpenSSL 1.0.2 or
later.  Now OpenSSL 1.0.2 is slated for EOL at the end of this year,
and 1.1.0 (not an LTS release) in September, so one may be tempted
to set the floor at 1.1.1, but that would probably leave some
supported O/S releases behind, that may still be supporting OpenSSL
1.0.2 beyond its upstream EOL.

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 1895] Default groups for DH possibly backdoored

[Viktor Dukhovni via Exim-dev]

On Tue, Mar 19, 2019 at 02:43:04AM +, admin--- via Exim-dev wrote:

> --- Comment #9 from Phil Pennock  ---
> IMO yes we're ready to drop support for older OpenSSL.  We set a clear policy,
> it's over a year (or two?) after that point, and other projects have adopted
> similar policies.

FWIW, Postfix 3.4, released a few weeks ago no longer supports
OpenSSL versions prior to 1.0.2.

Though folks on this list probably don't care, Postfix support
covers and the current and 3 previous stable releases, so we're
still supporting Postfix 3.1, 3.2 and 3.3 which build with older
OpenSSL releases, all the way back to 0.9.7, but DANE support
requires at least OpenSSL 1.0.0.  So users who're stuck with
OpenSSL 1.0.2 can continue to use it, with a slightly older
Postfix release, until 3.4 becomes the oldest supported stable
release.

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2311] New: DANE verify fails with a TA-mode TLSA and a selfsigned sever cert

[Viktor Dukhovni via Exim-dev]

> On Sep 9, 2018, at 1:04 PM, Jeremy Harris via Exim-dev  
> wrote:
> 
> https://lists.exim.org/lurker/message/20180904.122640.3cbadefb.en.html
> 
> The subject says "self signed".
> If it's not expected to work, perhaps you could explain why (on-list,
> to the originator)?

The OP is not sufficiently familiar with the right terms of art.
He/she surely means private-CA, not found in the local trust
store, rather than self-signed server certificate.

  self-signed root CA (not in Mozilla bundle)
|
v
  [ intermediates ]
|
v
  EE cert

DANE-TA(2) works when the trust-anchor certificate matches some
*issuer* certificate in the chain provided by the server in its
"TLS certificate message".  If the match is the self-signed
root CA, that certificate MUST be included in the chain for DANE
to work, even though root CAs are not typically sent with WebPKI
PKIX.

The lists.gentoo.example matches both an intermediate and a root,
and both are included in the server chain.  So the issue to focus
on is why lists.gentoo.org (or ditto with just gentoo.org) fails.

DANE-TA(2) never matches a self-signed EE cert.

-- 
Viktor.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2311] New: DANE verify fails with a TA-mode TLSA and a selfsigned sever cert

[Viktor Dukhovni via Exim-dev]

> On Sep 9, 2018, at 10:50 AM, admin--- via Exim-dev  wrote:
> 
>   Summary: DANE verify fails with a TA-mode TLSA and a selfsigned
>sever cert
>   Product: Exim
>   Version: 4.91
>  Hardware: x86
>OS: Windows
>Status: NEW
>  Severity: bug
>  Priority: medium
> Component: Delivery in general
>  Assignee: ni...@exim.org
>  Reporter: jgh146...@wizmail.org
>CC: exim-dev@exim.org
> 
> This appears to be a GnuTLS library bug at present, but recording here for
> tracking purposes.

This does not appear to be the right description.  DANE-TA(2) is NOT
expected to work with self-signed server certs, and the report for
lists.gentoo.org is not for a self-signed cert.

The reports seem to be for ordinary 2 or 3 level chains in which
DANE-TA(2) matches at depth 1 or higher (depth 0 is the EE cert).

-- 
Viktor.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2298] tls_eccurve does not accept multiple entries

[Viktor Dukhovni via Exim-dev]

> On Aug 10, 2018, at 4:24 AM, admin--- via Exim-dev  wrote:
> 
> Most uses should leave tls_eccurve at the default "auto".  With a modern
> version of OpenSSL this will support the full set of curves known to the
> library.
> 
> The use of accepting a list for tls_eccurve would be restricted to cases of
> "more than one, but not the full set".  I'm not sure how common that need is.

If you do decide to support multiple specific curves, the appropriate
interface is SSL_CTX_set1_curves_list(3):

https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_set1_curves_list.html

int SSL_CTX_set1_curves_list(SSL_CTX *ctx, char *list);

SSL_CTX_set1_curves_list() sets the supported curves for ctx to
string list.  The string is a colon separated list of curve NIDs
or names, for example "P-521:P-384:P-256".

Note that there's no mention of support for spaces around the ":"
separators.  Exim could, if this was considered sufficiently useful,
look for a colon in the parameter value, and if one were found,
call SSL_CTX_set1_curves_list(3) instead of:

int SSL_CTX_set_ecdh_auto(SSL_CTX *ctx, int onoff);

Not saying this is necessary, but it is an option with OpenSSL >= 1.0.2.

-- 
Viktor.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] DNSSEC / log spam

[Viktor Dukhovni via Exim-dev]

On Sat, Jun 30, 2018 at 02:45:31AM -0400, Phil Pennock wrote:

> On 2018-06-30 at 00:01 -0400, Viktor Dukhovni via Exim-dev wrote:
> >  So there is a potential solution, if you're
> > willing to change how manage _res.options.
> 
> No.  Messing with _res was always dangerous and since NetBSD went and
> made incompatible changes, life became hell.

OK, but just as a data point, over in Postfix-land we've not had
any trouble with _res in the legacy resolver API on any supported
platforms.  And if you use res_ninit() you get to have your own
private resolver state.  So it is not clear why Exim would have
such troubles.  Exim is not multi-threaded IIRC.

Anyway, I should not persist, just trying to be helpful, and don't
want to be a pest... So no more, unless you have questions.

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2264] DNS lookups should not chase CNAME chains

[Viktor Dukhovni via Exim-dev]

> On Jun 9, 2018, at 7:50 PM, Jeremy Harris via Exim-dev  
> wrote:
> 
>> OK, that's what I'd expect, from this you can conclude
>> that "nomx.example" has no MX records.
> 
> With a retry count of one, and the current coding, it failed
> when it hit that case.  It was far simpler to loop once than
> try to rewrite all the code.

My concern would be that if the code is unable to draw the
right conclusion from just the initial response (i.e. it
does not parse all the records to build a chain to the
final target, and check for the presence or absence of
the answer for that target), then one extra query could
also be insufficient.  CNAME chains can be multiple
elements long (10 is a popular limit).  A classic
example is:

  $ dig +noall +ans +nocl +nottl -t a www.paypal.com
  www.paypal.com. CNAME   geo.paypal.com.akadns.net.
  geo.paypal.com.akadns.net. CNAME hotspot-www.paypal.com.akadns.net.
  hotspot-www.paypal.com.akadns.net. CNAME wlb.paypal.com.akadns.net.
  wlb.paypal.com.akadns.net. CNAME www.paypal.com.edgekey.net.
  www.paypal.com.edgekey.net. CNAME e3694.a.akamaiedge.net.
  e3694.a.akamaiedge.net. A   104.123.10.240

which arrives as a single DNS response.

-- 
Viktor.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2264] DNS lookups should not chase CNAME chains

[Viktor Dukhovni via Exim-dev]

> On Jun 9, 2018, at 7:17 PM, Jeremy Harris via Exim-dev  
> wrote:
> 
> It was:
> 
>  Zone:
>cname.example. IN CNAME nomx.example.
>nomx.example. IN A 192.0.2.1
>  Query:
>cname.example. IN MX ?
>  Response:
>Answers:
>  cname.example. IN CNAME nomx.example.

OK, that's what I'd expect, from this you can conclude
that "nomx.example" has no MX records.  No additional
query required.  You can then proceed to A/
queries for the final target...  Provided you
process *all* the CNAME records from the initial
response to re-construct the entire chain, and
make sure that the final chain element has no
associated MX RRs in the same answer (retry over
TCP if the answer is truncated).

In other words I don't yet see a need to do
"recursion" to chase the CNAME chain beyond
the nameservers initial reply...

-- 
Viktor.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2264] DNS lookups should not chase CNAME chains

[Viktor Dukhovni via Exim-dev]

> On Jun 9, 2018, at 5:27 PM, admin--- via Exim-dev  wrote:
> 
> 
> Git Commit  changed:
> 
>   What|Removed |Added
> 
> CC||g...@exim.org
> 
> --- Comment #2 from Git Commit  ---
> Git commit:
> https://git.exim.org/exim.git/commitdiff/d8d9f9301c9a31c826635bbdd334bb4be99ea05a
> 
> commit d8d9f9301c9a31c826635bbdd334bb4be99ea05a
> Author: Jeremy Harris 
> AuthorDate: Thu Jun 7 18:08:22 2018 +0100
> Commit: Jeremy Harris 
> CommitDate: Thu Jun 7 18:08:22 2018 +0100
> 
>follow cname chains only one step.  bug 2264
> 
> doc/doc-docbook/spec.xfpt| 14 ++
> doc/doc-txt/ChangeLog|  7 +++
> doc/doc-txt/OptionLists.txt  |  1 +
> src/README.UPDATING  |  8 
> src/src/dns.c| 19 +--
> src/src/globals.c|  1 +
> src/src/globals.h|  1 +
> src/src/readconf.c   |  1 +
> src/src/verify.c |  5 ++---
> test/aux-var-src/tls_conf_prefix |  1 +
> test/stdout/0572 |  2 ++
> test/stdout/0577 |  1 +
> 12 files changed, 52 insertions(+), 9 deletions(-)

I am confused by the comments in the bug tracker and code.
Can you share the cases you found that make it necessary
to recurse one extra time?

I would expect the following behaviour from an iterative
resolver:

  Zone:
cname.example. IN CNAME cname2.example.
cname2.example. IN CNAME nomx.example.
nomx.example. IN A 192.0.2.1
  Query:
cname.example. IN MX ?
  Response: 
Header.RCODE: NOERROR
Answers:
  cname.example. IN CNAME cname2.example.
  cname2.example. IN CNAME nomx.example.

>From which, without further recursion one may
conclude that "cname.example" has no MX RRs.
Per RFC5321, one can treat "nomx.example" as
the destination domain with an implicit MX
RRset of:

nomx.example. IN MX 0 nomx.example.

The "AD" bit from the response indicates whether
the chain from "cname.example." to "nomx.example."
is secure, and opportunistic DANE support can be
engaged accordingly.

If the RCODE is "NXDOMAIN", the original name
or else the final CNAME target does not exist.

If the RCODE is "NOERROR" and MX records are
returned for the final CNAME target:

cname3.example. IN CNAME cname4.example.
cname4.example. IN CNAME hasmx.example.
hasmx.example. IN MX 0 smtp.hasmx.example.

then the resolver should return an answer containing
both CNAMEs and the MX records of the final target.

If the resolver is unable to reach the end of the
chain (due to loops, timeouts, recursion limits, ...)
it should return SERVFAIL.

Are you seeing something else?

-- 
Viktor.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2266] TLS SNI should default set

[Viktor Dukhovni via Exim-dev]

> On Apr 20, 2018, at 7:41 PM, Phil Pennock  wrote:
> 
> Yes: when you define a "smarthost" Router, you use "manualroute" as the
> driver, and choose the Transport to go with it.
> 
> It's absolutely reasonable and normal in Exim to:
> 
> 1. Have two similar Transports, referenced by different drivers (you can
>   use one with expansion options but that can increase complexity,
>   often it's most maintainable to have a clean separation)
> 2. Define a remote_smtp_smarthost Transport which just sets
>"tls_sni = $host" in that case.

Question about this "$host".  Are smarthost settings ever subject to
MX lookups, so that the actual remote SMTP server is one of the MX
hosts of the smarthost domain?

In both Sendmail and Postfix, when the relayhost is not enclosed in
"[]", the SMTP server used is obtained indirectly via MX lookups,
but when the relayhost is enclosed in "[]" then that's the verbatim
SMTP server to use.  In either case the "next-hop" domain is the
specified relayhost (before any MX lookup).

The plan for client-side SNI support in Postfix is to allow global
settings of the form:

smtp_tls_server_name =  | "next-hop" | "hostname" | 

where  (the default) leaves SNI disabled, while "next-hop" and
"hostname" are respectively the next-hop domain and MX hostname.
Per-destination settings would have a similar keyword in the TLS policy table.

If there's a sound way to do something similar, IMHO that's about the
right approach, with the user choosing no-SNI, a literal value or
whatever the next-hop domain is (recipient domain or smarthost when
applicable) or the MX host when that's the right value.

Note that insecure choices of SNI are not disasterous, it's just the
hint you send to the remote server, you're still validating the cert
you get based on whatever the policy is for that.

Of course I'm entirely unfamiliar with how context is managed in Exim,
and what's available in expansions and when, so perhaps there's not
an easy way to expose the original smarthost name as "next-hop" and
have that be the envelope recipient domain otherwise.

-- 
Viktor.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2266] TLS SNI should default set

[Viktor Dukhovni via Exim-dev]

> On Apr 20, 2018, at 7:07 PM, admin--- via Exim-dev  wrote:
> 
> Because unless you have DNSSEC, $host is derived via insecure means, the DNS. 
> DNSSEC means that DNS becomes secure for our purposes.
> 
> If you have DNSSEC and want $host sent, then publish TLSA records to enable
> DANE, and the other tracking bug will cover our fixing Exim to honor those for
> selecting the SNI value to send.
> 
> There is never any point in setting TLS SNI to a value which you are not
> willing to validate as being correct, referring back to a trusted path of
> input.  If some people run self-signed without SNI but CA-signed with SNI, 
> then
> that's a bug, but for MTAs delivering to MX it makes no difference because by
> default MX TLS *IS NOT VALIDATED*.
> 
> So, no DNSSEC, need a value, needs to be tied back to the recipient in a
> trustworthy way, thus $domain is all we have to go on.
> 
> It's not good.  It's simply the least bad option available.

In Postfix we have a notion that is the "next-hop" domain,
which is normally the envelope recipient domain, but when
a smarthost (or domain whose MX records are used for routing)
is specified, then the next-hop domain is the smarthost.

This provides a "secure" name for TLS policy lookup, and is
not subject to insecure DNS downgrades.  This is available
for peer name matching, and will also be available for 
client-side SNI when I get that implemented (shortly).

Is there anything similar in Exim?

-- 
Viktor.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] TLS 1.3 *does not* mandate SNI.

[Viktor Dukhovni via Exim-dev]

> On Apr 17, 2018, at 8:10 PM, Viktor Dukhovni via Exim-dev <exim-dev@exim.org> 
> wrote:
> 
> If they have a default certificate chain that works with TLS 1.2
> withholding it with TLS 1.3 seems rather rude...  I'll chat with
> David Benjamin, perhaps he'll have good reasons for this that I'm
> missing, but off hand it seems counter-productive.

I've reproduced this with [gmail-smtp-in.l.google.com] and posttls-finger
linked against the OpenSSL 1.1.1 library.  When sending a TLS client HELLO
that supports TLS 1.3, but no SNI the Google SMTP server negotiates TLS
1.2 (not 1.3), but with the self-signed cert.  When using the OpenSSL 1.1.0
liobraries, it negotiates TLS 1.2 with the usual certificate chain.

This is rather annoying, and we may have to bump the OpenSSL library SONAME
as a result, so that applications don't suddenly find themselves unable
to authenticate servers they could previously authenticate.

This could affect users who've configured secure-channel TLS with Gmail,
but have not set up SNI (not presently configurable outside of DANE in
Postfix, for example).

-- 
Viktor.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] TLS 1.3 *does not* mandate SNI.

[Viktor Dukhovni via Exim-dev]

> On Apr 17, 2018, at 8:03 PM, Viktor Dukhovni  wrote:
> 
>> This came up because, today, Google's servers are responding to TLS1.3
>> connections which don't send SNI with a self-signed certificate which
>> has DN:
>> 
>> OU=No SNI provided; please fix your client., CN=invalid2.invalid
>> 
>> So Google are telling sending systems that they're broken and need to be
>> fixed.  I saw that string in my MTA logs and went investigating.
> 
> Which Google servers are these?  Are they MX hosts for some domains???
> If so, I need to tell Google urgently to cease and desist, this is
> wrong.

On the other hand, for opportunistic TLS, who cares if they return some
self-signed certificate, so long as the handshake completes with that
certificate, we're good.

The real problem will be if applications that previously sent no SNI
with TLS 1.2 in OpenSSL 1.1.0 are run-time linked with the OpenSSL
1.1.1 libraries (same SONAME) and no start doing TLS 1.3, and find
that they now fail to authenticate Google.  This sort of enforcement
will backfire and have the effect of turning off TLS 1.3, not getting
users to rewrite applications to send SNI.

If they have a default certificate chain that works with TLS 1.2
withholding it with TLS 1.3 seems rather rude...  I'll chat with
David Benjamin, perhaps he'll have good reasons for this that I'm
missing, but off hand it seems counter-productive.

-- 
Viktor.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] TLS 1.3 *does not* mandate SNI.

[Viktor Dukhovni via Exim-dev]

> On Apr 17, 2018, at 7:09 PM, Phil Pennock  wrote:
> 
> I agree the spec shows we can argue it's not required, but the spec also
> allows recipients to argue that it is required.
> 
> This came up because, today, Google's servers are responding to TLS1.3
> connections which don't send SNI with a self-signed certificate which
> has DN:
> 
>  OU=No SNI provided; please fix your client., CN=invalid2.invalid
> 
> So Google are telling sending systems that they're broken and need to be
> fixed.  I saw that string in my MTA logs and went investigating.

Which Google servers are these?  Are they MX hosts for some domains???
If so, I need to tell Google urgently to cease and desist, this is
wrong.

-- 
Viktor.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] TLS 1.3 *does not* mandate SNI.

[Viktor Dukhovni via Exim-dev]

The mandatory to implement language in the TLS 1.3 spec does not mean 
"mandatory to use", in particular, while servers must tolerate the extension, 
clients are not obligated to sen d it:

https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.4.2.2

   -  The "server_name" [RFC6066] and "certificate_authorities"
  extensions are used to guide certificate selection.  As servers
  MAY require the presence of the "server_name" extension, clients
  SHOULD send this extension, when applicable.

SHOULD is of course a strong incentive, but it is not a MUST, and, if no SNI 
can be reasonably inferred, and particularly if not authenticating the peer, 
the SNI can
be left out.  Time will tell whether there are more servers that screw up by 
aborting
when receiving an SNI for which they don't have an exactly matching 
certificate, or
by mandating SNI with TLS 1.3 despite serving a mostly opportunistic protocol!

While the TLS 1.3 protocol does allow servers to insist on SNI:

   Additionally, all implementations MUST support use of the
   "server_name" extension with applications capable of using it.
   Servers MAY require clients to send a valid "server_name" extension.
   Servers requiring this extension SHOULD respond to a ClientHello
   lacking a "server_name" extension by terminating the connection with
   a "missing_extension" alert.

Such insistence will quickly run into interop issues with opportunistic
TLS from e.g. Postfix, where SNI will not be sent by default.  I expect
that MTAs (as opposed to perhaps MSAs) will not require SNI.

-- 
Viktor.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2265] TLS SNI not auto-set for DANE clients

[Viktor Dukhovni via Exim-dev]

> On Apr 17, 2018, at 4:37 PM, admin--- via Exim-dev  wrote:
> 
> SNI for a DANE-advertising site has to be different than one that does not?
> Sheesh.  Does that not implicitly require that _all_ clients be DANE-aware,
> or that _all_ DANE-advertising hosts be prepared to be hit with SNI from
> non-DANE-aware clients (and still do the right thing)?
> 
> I think SNI just became useless.

A host with TLSA records should expect DANE clients to send the MX hostname
as the SNI name.  Other clients might use other SNI names or none at all.
I don't see how SNI becomes useless.  If you've got a matching cert, send
that, if not send a default cert.

-- 
Viktor.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2264] New: DNS lookups should not chase CNAME loops

[Viktor Dukhovni via Exim-dev]

> On Apr 17, 2018, at 3:58 PM, admin--- via Exim-dev  wrote:
> 
> Per the discussion starting
> https://lists.dns-oarc.net/pipermail/dns-operations/2018-April/017449.html
> we should trust that the resolver is doing the right thing, following CNAME
> chains itself - meaning that a CNAME return from a CNAME lookup will always
> be an infinite loop and should be treated as NODATA.  The limited loop we
> have can be removed so we do not hammer the resolver.

Specifically, the relevant guidance is in:

   https://tools.ietf.org/html/rfc6604#section-3

which explains that the RCODE for a response (with qtype != CNAME) in which the 
initial qname leads to a CNAME indicates the status of the query for the 
requested qtype at the final CNAME in the chain.  This means (modulo DNSSEC 
failures, which lead to ServFail):

1.  If the final name has data for the requested type,
it must be present in the response (modulo truncation,
which should lead to TCP retries...).  The RCODE is then NOERROR

2.  If the final name has no data of the requested type, the RCODE
is still NOERROR, and no data of the requested type is provided.
(thus effectively NODATA).

3.  If the final name does not exist, the RCODE is NXDOMAIN

4.  If the resolver exceeded its recursion limit the RCODE is SERVEFAIL

5.  If there's a CNAME loop, the RCODE is typically SERVFAIL, but some
nameservers return the looping CNAMEs and NOERROR, only reported
with BIND when the final CNAME is a direct loop (x -> x).

This means that the DNS client can always infer all it needs from a single
response, and should make iterative queries for each (or any) returned
CNAMEs.  Instead it should be willing to iteratively parse the original
response chasing CNAMEs within the response to find the requested data.
Note that the order of RRsets in the response is not guaranteed, and in
theory the answer may come before the CNAMEs and the CNAMEs might not be
in order (neither "pathology" is common, but sadly one must be prepared).

-- 
Viktor.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2266] New: TLS SNI should default set

[Viktor Dukhovni via Exim-dev]

> On Apr 17, 2018, at 4:17 PM, admin--- via Exim-dev  wrote:
> 
> Handling for DANE should be in issue 2265.  DANE should stop using the tls_sni
> SMTP Transport option and DANE handling is not in-scope for _this_ tracking
> bug.
> 
> IMO tls_sni should default to $domain, which requires disabling multi_domain 
> by
> default.

Not sure what you mean by "$domain", but the DANE SNI *must* be the TLSA
base domain, which is typically the MX hostname (but sometimes its full
CNAME expansion).  It is only the nexthop domain when the domain has no
MX records (implicit MX) or an explicit MX whose name is the domain itself.

Thus for:

example.net. IN MX 0 smtp.example.net.
smtp.example.net. IN A 192.0.2.1
_25._tcp.smtp.example.net. IN TLSA 3 1 1 ...

the SNI value must be "smtp.example.net" not "example.net".
The SMTP server must not abort the handshake when it finds
no matching certificate, rather it must select some
appropriate default chain.

-- 
Viktor.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2255] TLS/SSL issue after upgading to 4.90

[Viktor Dukhovni via Exim-dev]

> On Apr 4, 2018, at 2:35 PM, admin--- via Exim-dev  wrote:
> 
> We are ready to attach any dumps of exim debug or wireshark if it's necessary.

A "tshark" decode of the TLS handshake (text is better than screenshots) would
be most useful, one where the session cache mode is per the upstream patch, and
another where it is left at the default (the code setting the mode is removed).

Capture a PCAP file of the traffic with:

   # port=587 # (or 465 as appropriate)
   # tcpdump -s0 -w /some/file tcp port $port
   ... hit control-C when you think you've captured enough relevant traffic...

and post the decode for a single session from:

   $ tshark -r /some/file -d tcp.port==$port,ssl -V |
sed -ne '/^Secure Sockets Layer/,/^$/p'

You can pre-filter the PCAP file to extract just the data for a particular
client session by IP and/or client TCP port:

 # tcpdump -s0 -r /some/file -w /some/other-file tcp port $client_port and host 
$client_ip
 # tcpdump -s0 -r /some/file -w /some/other-file tcp port $client_port
 # tcpdump -s0 -r /some/file -w /some/other-file host $client_ip

then run tshark reading from "/some/other-file".

-- 
Viktor.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] Exim 4.91 RC1

[Viktor Dukhovni via Exim-dev]

> On Mar 17, 2018, at 11:05 PM, Phil Pennock via Exim-dev  
> wrote:
> 
> Oh: any preferences around OpenSSL 1.1.X for exim.org box?  We currently
> "drink our own champagne" when it comes to advice around OpenSSL
> libraries and deprecation, with 1.0.2n in /opt/openssl/.
> 
> I'm tentatively thinking that we can wait for OpenSSL 1.1.1 to reach
> Beta status, then have /opt/openssl111/ for that, and have port-25 Exim
> use 1.0.2 and port-26 Exim use 1.1.1, just skipping 1.1.0 entirely.  But
> I've not been doing the recent maintenance work on TLS in Exim, you
> have, so I'll (probably) defer to your preference here.

You may find the notes for the below commits to OpenSSL 1.1.0 and upcoming
1.1.1 useful for building alternate versions of OpenSSL "on the side":

https://github.com/openssl/openssl/commit/822b5e2645a99bea15329bd66c9723c7e7119cdb
https://github.com/openssl/openssl/commit/e6f38fb817d831ed093f7d7140325783b5556d8f

-- 
Viktor.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2255] TLS/SSL issue after upgading to 4.90

[Viktor Dukhovni via Exim-dev]

> On Mar 13, 2018, at 12:55 PM, admin--- via Exim-dev  wrote:
> 
> You would have to set NO_TICKET on the IMAP server, not
> Exim. 
> 
> What you could try, although I do not know whether it works, 
> is to set -no_ticket in Exim, thus disabling the disabling of
> tickets. Hopefully the effect is that Exim will hand out tickets.
> Those will never match the ones carried over from IMAP and Exim
> does not offer resume anyway, so no harm done. It might not do 
> anything at all, since NO_TICKET is hardcoded into the Exim sources.

Based on this thread, it sounds to me like Outlook expects the *same*
ticket (or more generally resumable session) to work across both IMAP
and SMTP submission.  If so, then if IMAP session caching is enabled,
no matter how you configure Exim, you can't win, because the IMAP
server and SMTP server don't have an integrated shared session cache!

The only "solution" is for both IMAP and submission to not offer
session resumption.

Mind you, if the submission client just reconnects to negotiate a new
session, rather that continue with a full handshake, and this is all
transparent to the user, then apart from some noise in the logs this
is completely harmless, and you could just leave it the way it is with
IMAP sessions cached (users read a lot more mail then the send).

-- 
Viktor.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2255] TLS/SSL issue after upgading to 4.90

[Viktor Dukhovni via Exim-dev]

> On Mar 12, 2018, at 2:03 PM, admin--- via Exim-dev  wrote:
> 
> I was found differences between failure and success on 4.90_1 and 4.89.
> But I'm absolutely puzzled how to copy readable packet description from
> Wireshark to clipboard.

There's an example of how to do this with tshark in:

   https://mta.openssl.org/pipermail/openssl-users/2017-April/005624.html

-- 
Viktor.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##