What is lost by using self-signed certs for TLS?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

What is lost by using self-signed certs for TLS?

Antonio Leding
Hello all,

Please allow me to apologize in advance for any ignorance here…and also, I have researched and am just not seeing the entire picture here.

My goal is to fully understand what is lost by using only self-signed certs on my PF server.  Here’s what I think I know:

— The fact that the cert is self-signed really only impacts mail coming into our organization from those who are outside the organization.
— Because the cert cannot be verified, only anonymous ciphers can be negotiated between my server and the other side’s client.

I have to believe there are more considerations here which of course is why I came to you all…

OK - please educate as required…and as always many thanks in advance...
Reply | Threaded
Open this post in threaded view
|

Re: What is lost by using self-signed certs for TLS?

Viktor Dukhovni
On Sun, Jul 26, 2020 at 02:45:38AM +0000, Antonio Leding wrote:

> My goal is to fully understand what is lost by using only self-signed
> certs on my PF server.  Here’s what I think I know:
>
> — The fact that the cert is self-signed really only impacts mail
> coming into our organization from those who are outside the
> organization.

Assuming that no internal system fails to implement opportunistic TLS in
a sane manner.

> — Because the cert cannot be verified, only anonymous ciphers can be
> negotiated between my server and the other side’s client.

No. that's false.  A majority of clients will solicit certificates they
then proceed to ignore.  It's to some extent a cargo-cult thing, someone
on the Internet said that anonymous ciphers are insecure, and so users
avoid them, though they don't exactly know why.  But the sickness is
deep, TLS 1.3 has completely removed support for anonymous ciphers, so
in a few years their use will be rather exotic.

> I have to believe there are more considerations here which of course
> is why I came to you all…

A few brain-dead bulk mail systems (you probably don't care about),
abort the TLS handshake when they see a certificate chain they can't
verify, and then proceed to deliver in clear text, as though that's more
secure than using unauthenticated TLS.  Again cargo-cult, someone on the
Internet said that certificate verification is not optional.

Otherwise, you're free to use self-signed certs, they work just fine for
quite a lot of receiving systems.

You can even implement DNSSEC for your domain (with monitoring to
check that it is working, that signatures are not too close to
expiration, ...) and then publish DANE TLSA records:

    https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources

but again only if you also implement monitoring to ensure that
the certificate chain and TLSA records match, and a cert rollover
process that avoids periodic outages caused by rolling the cert
and TLSA RRs at the same time and ignoring remote caches, and/or
older authoritative zone data on secondary servers.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: What is lost by using self-signed certs for TLS?

Antonio Leding
Hi Victor…

Thanks so much for the feedback…very helpful…

I’ve always been dubious about the auth requirement by some (i.e. the brain deads to which you refer) to allow TLS connections for server-to-server communications.  My view is this — when my server sends outbound mail, do I really care that the server I looked up via DNS is who they purport to be in the cert?  I have to imagine if a bad actor is able to somehow hack\forge DNS records that they will also be able to take care of the cert especially given that LE is free and very easy to obtain after the DNS has been cfg’d.

In any event, people do what people do so I guess in order to ensure my server will employ the highest number of TLS sessions, I should use a CA-signed cert...  

Agreed?


> On Jul 25, 2020, at 8:03 PM, Viktor Dukhovni <[hidden email]> wrote:
>
> On Sun, Jul 26, 2020 at 02:45:38AM +0000, Antonio Leding wrote:
>
>> My goal is to fully understand what is lost by using only self-signed
>> certs on my PF server.  Here’s what I think I know:
>>
>> — The fact that the cert is self-signed really only impacts mail
>> coming into our organization from those who are outside the
>> organization.
>
> Assuming that no internal system fails to implement opportunistic TLS in
> a sane manner.
>
>> — Because the cert cannot be verified, only anonymous ciphers can be
>> negotiated between my server and the other side’s client.
>
> No. that's false.  A majority of clients will solicit certificates they
> then proceed to ignore.  It's to some extent a cargo-cult thing, someone
> on the Internet said that anonymous ciphers are insecure, and so users
> avoid them, though they don't exactly know why.  But the sickness is
> deep, TLS 1.3 has completely removed support for anonymous ciphers, so
> in a few years their use will be rather exotic.
>
>> I have to believe there are more considerations here which of course
>> is why I came to you all…
>
> A few brain-dead bulk mail systems (you probably don't care about),
> abort the TLS handshake when they see a certificate chain they can't
> verify, and then proceed to deliver in clear text, as though that's more
> secure than using unauthenticated TLS.  Again cargo-cult, someone on the
> Internet said that certificate verification is not optional.
>
> Otherwise, you're free to use self-signed certs, they work just fine for
> quite a lot of receiving systems.
>
> You can even implement DNSSEC for your domain (with monitoring to
> check that it is working, that signatures are not too close to
> expiration, ...) and then publish DANE TLSA records:
>
>    https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources
>
> but again only if you also implement monitoring to ensure that
> the certificate chain and TLSA records match, and a cert rollover
> process that avoids periodic outages caused by rolling the cert
> and TLSA RRs at the same time and ignoring remote caches, and/or
> older authoritative zone data on secondary servers.
>
> --
>    Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: What is lost by using self-signed certs for TLS?

Viktor Dukhovni
On Mon, Jul 27, 2020 at 07:32:41PM +0000, Antonio Leding wrote:

> I’ve always been dubious about the auth requirement by some (i.e. the
> brain deads to which you refer) to allow TLS connections for
> server-to-server communications.

Without DANE or (weaker) MTA-STS, indeed X.509 authentication of SMTP MX
hosts is mere appearance of security.

> In any event, people do what people do so I guess in order to ensure
> my server will employ the highest number of TLS sessions, I should use
> a CA-signed cert...  

That's not the conclusion I reached.  My MTA uses a self-signed cert.
The domains that abort STARTTLS with untrusted certs are few and don't
send anything sensitive.

> Agreed?

You can of course use an LE cert, it does not do any obvious harm,
unless you also do DANE, and neither freeze the key, nor handle TLSA
updates correctly (in advance of cert deployment).

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: What is lost by using self-signed certs for TLS?

Antonio Leding
> You can of course use an LE cert, it does not do any obvious harm,
> unless you also do DANE, and neither freeze the key, nor handle TLSA
> updates correctly (in advance of cert deployment).

So I’m gathering (a) not much will be gained by using a public-A signed cert; and (b) the PROs of using DANE + self-signed likely (or actually) outweigh going with an LE cert sans DANE.



> On Jul 27, 2020, at 1:52 PM, Viktor Dukhovni <[hidden email]> wrote:
>
> On Mon, Jul 27, 2020 at 07:32:41PM +0000, Antonio Leding wrote:
>
>> I’ve always been dubious about the auth requirement by some (i.e. the
>> brain deads to which you refer) to allow TLS connections for
>> server-to-server communications.
>
> Without DANE or (weaker) MTA-STS, indeed X.509 authentication of SMTP MX
> hosts is mere appearance of security.
>
>> In any event, people do what people do so I guess in order to ensure
>> my server will employ the highest number of TLS sessions, I should use
>> a CA-signed cert...  
>
> That's not the conclusion I reached.  My MTA uses a self-signed cert.
> The domains that abort STARTTLS with untrusted certs are few and don't
> send anything sensitive.
>
>> Agreed?
>
> You can of course use an LE cert, it does not do any obvious harm,
> unless you also do DANE, and neither freeze the key, nor handle TLSA
> updates correctly (in advance of cert deployment).
>
> --
>    Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: What is lost by using self-signed certs for TLS?

Viktor Dukhovni
On Mon, Jul 27, 2020 at 08:58:19PM +0000, Antonio Leding wrote:
> > You can of course use an LE cert, it does not do any obvious harm,
> > unless you also do DANE, and neither freeze the key, nor handle TLSA
> > updates correctly (in advance of cert deployment).
>
> So I’m gathering (a) not much will be gained by using a public-A
> signed cert; and (b) the PROs of using DANE + self-signed likely (or
> actually) outweigh going with an LE cert sans DANE.

Yes, (a) not much gained.

And, (b) while it is not in principle that difficult to combine DANE
with automated renewal of Let's Encrypt certs, some struggle getting all
the gears to move in unison.

If you do want to secure your inbound email, do consider DANE, but
make sure that the first thing you implement is monitoring that
checks whether DANE is working correctly, then a robust rollover
process that ensures that even somewhat stale TLSA records (in
secondary nameservers or downstream caches) never fail to
match the deployed certificate chain.

Once you have monitoring, and sound rollover process, enable DANE.
You'll of course need to have a DNSSEC-signed domain, and monitoring for
that too (including checking that signatures on key RRsets are not
unexpectedly close to expiring).

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: What is lost by using self-signed certs for TLS?

Antonio Leding
Again, great feedback…I am definitely diving into DANE now…may have more questions but I will try to keep those to a minimum.

Thanks again Victor - very much appreciated…


> On Jul 27, 2020, at 2:44 PM, Viktor Dukhovni <[hidden email]> wrote:
>
> On Mon, Jul 27, 2020 at 08:58:19PM +0000, Antonio Leding wrote:
>>> You can of course use an LE cert, it does not do any obvious harm,
>>> unless you also do DANE, and neither freeze the key, nor handle TLSA
>>> updates correctly (in advance of cert deployment).
>>
>> So I’m gathering (a) not much will be gained by using a public-A
>> signed cert; and (b) the PROs of using DANE + self-signed likely (or
>> actually) outweigh going with an LE cert sans DANE.
>
> Yes, (a) not much gained.
>
> And, (b) while it is not in principle that difficult to combine DANE
> with automated renewal of Let's Encrypt certs, some struggle getting all
> the gears to move in unison.
>
> If you do want to secure your inbound email, do consider DANE, but
> make sure that the first thing you implement is monitoring that
> checks whether DANE is working correctly, then a robust rollover
> process that ensures that even somewhat stale TLSA records (in
> secondary nameservers or downstream caches) never fail to
> match the deployed certificate chain.
>
> Once you have monitoring, and sound rollover process, enable DANE.
> You'll of course need to have a DNSSEC-signed domain, and monitoring for
> that too (including checking that signatures on key RRsets are not
> unexpectedly close to expiring).
>
> --
>    Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: What is lost by using self-signed certs for TLS?

Viktor Dukhovni
On Mon, Jul 27, 2020 at 09:48:29PM +0000, Antonio Leding wrote:

> Again, great feedback…I am definitely diving into DANE now…may have
> more questions but I will try to keep those to a minimum.

https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: What is lost by using self-signed certs for TLS?

Antonio Leding
Thanks Victor - actually watching some of the presos now…

BTW…any choice you like for DNSSEC providers?  Google seems like a safe bet but I figured you might have some feedback on this as well…



> On Jul 27, 2020, at 3:36 PM, Viktor Dukhovni <[hidden email]> wrote:
>
> On Mon, Jul 27, 2020 at 09:48:29PM +0000, Antonio Leding wrote:
>
>> Again, great feedback…I am definitely diving into DANE now…may have
>> more questions but I will try to keep those to a minimum.
>
> https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources
>
> --
>    Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: What is lost by using self-signed certs for TLS?

Viktor Dukhovni
On Mon, Jul 27, 2020 at 10:55:31PM +0000, Antonio Leding wrote:

> Thanks Victor - actually watching some of the presos now…
>
> BTW…any choice you like for DNSSEC providers?  Google seems like a safe bet but I figured you might have some feedback on this as well…

I self-host, so my direct experience is limited.  Google are signing a
lot of domains lately.  On any given day, most of the newly signed
domains are operated by them, so they certainly are doing it at scale.

In Europe, there are many providers that also host DANE TLSA RRs for
their DNS+MX hosted domains.

    one.com
    transip.nl
    domeneshop.no
    ...

    https://mail.sys4.de/pipermail/dane-users/2020-July/000571.html

Though somewhat out of date (I update it infrequently), the below shows
which MX-hosting providers have many DNSSEC-signed customer domains:

    http://dnssec-stats.ant.isi.edu/~viktor/hosters.html

Cloudflare also does DNSSEC hosting, but does not do much if any email
hosting, so don't show up in the above stats.  At some point I should
starting populating NS and/or SOA records to the DANE survey database,
which would provide better insight into who operates DNSSEC-signed
domains.  Presently, I only collect the DS, DNSKEY, MX, A, AAAA and
TLSA RRs, which cover the MX-operator, but not the DNS operator.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

RE: What is lost by using self-signed certs for TLS?

Scott Hollenbeck
In reply to this post by Antonio Leding
> -----Original Message-----
> From: [hidden email] <[hidden email]>
> On Behalf Of Antonio Leding
> Sent: Monday, July 27, 2020 6:56 PM
> To: [hidden email]
> Subject: Re: What is lost by using self-signed certs for TLS?
>
> Thanks Victor - actually watching some of the presos now…
>
> BTW…any choice you like for DNSSEC providers?  Google seems like a safe
> bet but I figured you might have some feedback on this as well…

I use Google. They've been reliable, inexpensive (for my small zones), and they do support DNSSEC and TLSA record publication. If you use them, you're going to need to do some scripting using the Let's Encrypt renewal hooks and gcloud to update your TLSA record(s) every time you renew your certificate(s). Viktor does some automated checking that's caught the few times when my TLSA re-generation script has gone awry, so don't worry, if you publish a bad TLSA record you'll find out soon enough!

Scott

Reply | Threaded
Open this post in threaded view
|

Re: What is lost by using self-signed certs for TLS?

Viktor Dukhovni
On Mon, Jul 27, 2020 at 07:53:09PM -0400, Scott Hollenbeck wrote:

> If you use them, you're going to need to do some scripting using the
> Let's Encrypt renewal hooks and gcloud to update your TLSA record(s)
> every time you renew your certificate(s). Viktor does some automated
> checking that's caught the few times when my TLSA re-generation script
> has gone awry, so don't worry, if you publish a bad TLSA record you'll
> find out soon enough!

I don't recommend relying solely on the DANE survey engine for
monitoring.  The alerts are neither especially timely, nor will continue
to be sent indefinitely.  One enough notices fail to break the pattern
of periodic outages, I stop sending the notices.

--
    Viktor.