The current versions of sSMTP doesn't attempt to validate the server
certificate when using TLS.  Without this, users authenticating over
encrypted connections might unknowingly be sending their
authentication information to a man in the middle.

The attached patch allows the user to configure a set of trusted
authorities which can be used to validate the server (`TLS_CA_File`
and `TLS_CA_Dir`).  If neither configuration option is given, the
current behavious (no validation) is preserved.

The attached patch should be applied after my patch for bug #662959
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662959).

Trevor

Hi, I have tried to use this patch in situation where ssmtp client is not
authenticating,  but I still want to have proper TLS connection to smtp
server. Found out the server SSL cert is not validated at all in this case. It
would be worthwhile addition.

There is an improved patch in Fedora, that validates the CA but still
not the hostname:
http://pkgs.fedoraproject.org/cgit/ssmtp.git/tree/ssmtp-validate-TLS-server-cert.patch

Dear Maintainer,

I'm changing the severity of this bug to 'serious'. I apologize if this
is presumptuous, but it seems to me that software that advertises TLS
functionality but neglects to check the supplied certificates is seriously
flawed. At the very least, the documentation should contain a Big Fat
Warning that the TLS functionality is limited to encryption and does not
include authentication of the server.

Any chance seeing this issue addressed or its severity lowered, so we can have the package in Buster ?

Given its purpose - "extremely simple MTA [...]" - should this issue really be considered "serious" (and Release Critical) ?

PS: ssmtp is extremely handy to forward machine-generated messages in large deployments, internally, iow. where TLS is not required

ssmtp seems like abandonware. Have you tried msmtp(-mta)? It works in a
similar way, is well supported and does the right thing when you want TLS.

Regards,
Simon

(I liked the extreme lightweight of ssmtp but so be it)

PS: one might also look at esmtp(-run)

Hi Celejar,

you have raised severity to "serious" on ssmtp Debian package
in bug #662960, which is reserved for "Serious policy violations" as
described at https://www.debian.org/Bugs/Developer#severities

It is customary to indicate exactly which section of Debian policy
Manual (at https://www.debian.org/doc/debian-policy/) the bug
breaks when setting "serious" severity.

While I do agree that limitations of TLS implementation should be
prominently noted in package documentation and even description, I do
not think that even completely non-existent TLS support qualifies for
more than "important" severity (and more likely "normal" or
"wishlist").

Unless someone objects with specific Debian policy section that this
package runs afoul, I'm going to revert its severity back to wishlist.

I concede that I was probably mistaken in raising the severity to
"serious". I was probably just so aggravated at the package promising
TLS support but silently failing to perform certificate validation
that I conflated the normal English meaning of "serious" with its
technical meaning in this context ;)

I do stand by my position that this is at least an "important" bug. I
agree that non-existent TLS support would be merely "wishlist" priority
- but not if the package assured the user that it was providing TLS but
silently failed to do so!

Another email in this report argues:

Again, while I concede that this may not technically be RC, pointing
to the software's self-description as an "extremely simple MTA [...]"
misses the point: I have no problem with insecure software (I'm not
filing any bugs against telnet ;)), only with software that assures the
user of a certain level of security but does not provide it.

Thank you for your work on Debian, and I apologize for my initial error.

Celejar

severity 662960 wishlist
thanks

The bug have been added tag "security", which is in sync with its TLS
deficiencies. However (as you noticed) "Severity" values (while they
might look innocently like plain English) have quite specific meanings
in BTS, which sometimes might be at odds with their common language
usages.

Because of that "Severity" is not just a number from 0-5 indicating
how much one would like for bug to be fixed, but something else.

"Severity: important" would indicate that package is just one small
step away from "rendering it completely unusable to everyone", which
looks too harsh to me in this case (as in many cases ssmtp is used
only for non-TLS plaintext SMTP delivery on LAN from satellite
machines to main MTA, which would then speak TLS to outside world
etc.)

"Severity: wishlist" however (as opposed to "normal") subtly
indicates that there is some functionality that is *missing*, and
that someone needs to think it over and write it, and that it might
be a more complicated task and probably not an one-line-fix (and thus
it would probably left to upstream to fix it, as Debian maintainer in
most cases won't be fixing it h[im/er]self unless upstream is dead
and someone else provides a verified good patch). It also indicates
it might be due to design decisions, like here.

I do agree completely with you that package should strongly indicate
in its docs and description about it's TLS deficiencies. If someone
would write such a documentation patch, perhaps it might have a
chance to be included.

[ As a side note, even with certificate checking in place there are a
lot of problems in todays "zillion untrusted CAs which we trust
anyway" security model, and even more so if you move from web
world (where clients try to be secure, and even people might
sometimes check basic credentials) to unattended MTA world where
almost nobody does, and vast majority of MTAs will simply by
default silently downgrade to plaintext if they think anything
might be problematic with TLS support etc. ]

On Wed, 6 Mar 2019 04:11:41 +0100 Matija Nalis <mnalis-debianbug@voyager.hr> wrote:

...

According to the documentation, "important" denotes:

"a bug which has a major effect on the usability of a package, without
rendering it completely unusable to everyone."

I would say that that misleading the user about certificate
verification should be considered "a major effect on the usability of
[the] package", but I think we've beat this horse to death, so I defer
to your judgment.

I'll try to write something and submit it here.

Celejar

On Wed, 6 Mar 2019 04:11:41 +0100 Matija Nalis <mnalis-debianbug@voyager.hr> wrote:

...

Attached are some documentation suggestions (I didn't touch the
manpage).

Celejar