9front - general discussion about 9front
 help / color / mirror / Atom feed
* patch smtp: ignore unrecognized certificates
       [not found] <aee5c8d2-ef2b-4ef2-8594-e6786cbd6e2e@sirjofri.de>
@ 2020-07-19  9:43 ` Joel Fridolin Meyer
  2020-07-20 14:05   ` [9front] " ori
  0 siblings, 1 reply; 21+ messages in thread
From: Joel Fridolin Meyer @ 2020-07-19  9:43 UTC (permalink / raw)
  To: 9front

[-- Attachment #1: Type: text/plain, Size: 1533 bytes --]

(This is a duplicate mail, because I'm not sure if the original mail from
my mail server is delivered correctly.)

Hello devs,

this patch adds a new flag -c to upas/smtp command ( smtp(8) ). This flag
removes the need to manually add thumbprints for tls certificates to
/sys/lib/tls/smtp, ignoring unrecognized certificates.

Thumbprints for unrecognized certificates will still be printed to
/sys/log/smtp, the message will still be sent.

If you want to add this to 9front, I'll be happily adjust the usage message
as well as the man page.

diff -r f8f63e944375 sys/src/cmd/upas/smtp/smtp.c
--- a/sys/src/cmd/upas/smtp/smtp.c  Fri Jul 17 16:53:20 2020 +0200
+++ b/sys/src/cmd/upas/smtp/smtp.c  Sun Jul 19 11:00:15 2020 +0200
@@ -46,6 +46,7 @@
int  quitting; /* when error occurs in quit */
int  tryauth;  /* Try to authenticate, if supported */
int  trysecure;  /* Try to use TLS if the other side supports it */
+int nocertcheck; /* ignore unrecognized certs. Still logged */

char *quitrv;  /* deferred return value when in quit */
char ddomain[1024];  /* domain name of destination machine */
@@ -185,6 +186,9 @@
case 'u':
user = EARGF(usage());
break;
+ case 'c':
+   nocertcheck = 1;
+   break;
default:
usage();
break;
@@ -420,7 +424,9 @@
}
if (!okCertificate(c->cert, c->certlen, goodcerts)) {
syslog(0, "smtp", "cert for %s not recognized: %r", ddomain);
-   goto Out;
+   if (!nocertcheck)
+     goto Out;
+   syslog(0, "smtp", "ignoring unrecognized cert");
}
syslog(0, "smtp", "started TLS to %q", ddomain);
err = nil;

[-- Attachment #2: Type: text/html, Size: 2036 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [9front] patch smtp: ignore unrecognized certificates
  2020-07-19  9:43 ` patch smtp: ignore unrecognized certificates Joel Fridolin Meyer
@ 2020-07-20 14:05   ` ori
  2020-07-20 14:20     ` hiro
  2020-07-20 16:18     ` cinap_lenrek
  0 siblings, 2 replies; 21+ messages in thread
From: ori @ 2020-07-20 14:05 UTC (permalink / raw)
  To: sirjofri, 9front

> this patch adds a new flag -c to upas/smtp command ( smtp(8) ). This flag
> removes the need to manually add thumbprints for tls certificates to
> /sys/lib/tls/smtp, ignoring unrecognized certificates.

I think this is a bad idea -- I'd prefer to make it more obvious how
to add the certificate in the first place. Possibly a upas/configmail
command that prompts for the server/login/..., and then gets the
thumbnail.

Ignoring the thumbprint entirely opens you up to MITM attacks.



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [9front] patch smtp: ignore unrecognized certificates
  2020-07-20 14:05   ` [9front] " ori
@ 2020-07-20 14:20     ` hiro
  2020-07-20 14:26       ` ori
  2020-07-20 16:18     ` cinap_lenrek
  1 sibling, 1 reply; 21+ messages in thread
From: hiro @ 2020-07-20 14:20 UTC (permalink / raw)
  To: 9front

isn't the issue that the cert keeps on randomly changing on server
side and thus making this "security" completely unachievable?

i maintain a similar patch for dillo so that i can visit https-only
websites that aren't worth protecting with SSL anyway.

whoever manually adds the certificates sometimes (Ori, do you?), do
you really check their validity?

once CAs are involved there's a lot of problems, and I doubt 9front is
in the position to change anything about that. that's why we have
dp9ik at least for our protocols and services :)

On 7/20/20, ori@eigenstate.org <ori@eigenstate.org> wrote:
>> this patch adds a new flag -c to upas/smtp command ( smtp(8) ). This flag
>> removes the need to manually add thumbprints for tls certificates to
>> /sys/lib/tls/smtp, ignoring unrecognized certificates.
>
> I think this is a bad idea -- I'd prefer to make it more obvious how
> to add the certificate in the first place. Possibly a upas/configmail
> command that prompts for the server/login/..., and then gets the
> thumbnail.
>
> Ignoring the thumbprint entirely opens you up to MITM attacks.
>
>


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [9front] patch smtp: ignore unrecognized certificates
  2020-07-20 14:20     ` hiro
@ 2020-07-20 14:26       ` ori
  2020-07-20 14:46         ` tlaronde
  0 siblings, 1 reply; 21+ messages in thread
From: ori @ 2020-07-20 14:26 UTC (permalink / raw)
  To: 23hiro, 9front

> whoever manually adds the certificates sometimes (Ori, do you?), do
> you really check their validity?

I run my own mail server, so the certificates don't change. I assume
that the first time I connect, it's valid.

How often do these certificates change?



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [9front] patch smtp: ignore unrecognized certificates
  2020-07-20 14:26       ` ori
@ 2020-07-20 14:46         ` tlaronde
  2020-07-20 14:52           ` ori
  2020-07-21  6:55           ` cinap_lenrek
  0 siblings, 2 replies; 21+ messages in thread
From: tlaronde @ 2020-07-20 14:46 UTC (permalink / raw)
  To: 9front

On Mon, Jul 20, 2020 at 07:26:08AM -0700, ori@eigenstate.org wrote:
> > whoever manually adds the certificates sometimes (Ori, do you?), do
> > you really check their validity?
> 
> I run my own mail server, so the certificates don't change. I assume
> that the first time I connect, it's valid.
> 
> How often do these certificates change?

It can be quite often. I have a certificate made via cacert.org for
example. And I have to renew it regularily. I think that
certificates with too long TTL are considered weak. So it's an
annoyance.
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                       http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [9front] patch smtp: ignore unrecognized certificates
  2020-07-20 14:46         ` tlaronde
@ 2020-07-20 14:52           ` ori
  2020-07-20 15:05             ` tlaronde
  2020-07-21  6:55           ` cinap_lenrek
  1 sibling, 1 reply; 21+ messages in thread
From: ori @ 2020-07-20 14:52 UTC (permalink / raw)
  To: tlaronde, 9front

> It can be quite often. I have a certificate made via cacert.org for
> example. And I have to renew it regularily. I think that
> certificates with too long TTL are considered weak. So it's an
> annoyance.

Hm. I see. Without some sort of check, anyone with a certificate
can MITM. I wonder how crazy it'd be to implement certificate
chain verification.



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [9front] patch smtp: ignore unrecognized certificates
  2020-07-20 14:52           ` ori
@ 2020-07-20 15:05             ` tlaronde
  2020-07-20 15:09               ` ori
  0 siblings, 1 reply; 21+ messages in thread
From: tlaronde @ 2020-07-20 15:05 UTC (permalink / raw)
  To: ori; +Cc: 9front

On Mon, Jul 20, 2020 at 07:52:04AM -0700, ori@eigenstate.org wrote:
> > It can be quite often. I have a certificate made via cacert.org for
> > example. And I have to renew it regularily. I think that
> > certificates with too long TTL are considered weak. So it's an
> > annoyance.
> 
> Hm. I see. Without some sort of check, anyone with a certificate
> can MITM. I wonder how crazy it'd be to implement certificate
> chain verification.

The problem is that if there is a chain, you need to trust the root you
finally end with. So whether this is a volunteers based C.A. or a
professional paying one. It's kind of squaring the circle. The solution
is to maintain one's network with an iron fist in a lead glove (because
lead is malleable so you can hit heavily while protecting the iron) and
to not trust anything outside and to not have to care about how much
untrustable is outside... Well, this generally means kicking out
users...
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                       http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [9front] patch smtp: ignore unrecognized certificates
  2020-07-20 15:05             ` tlaronde
@ 2020-07-20 15:09               ` ori
  2020-07-20 15:32                 ` hiro
  0 siblings, 1 reply; 21+ messages in thread
From: ori @ 2020-07-20 15:09 UTC (permalink / raw)
  To: 9front

> The problem is that if there is a chain, you need to trust the root you
> finally end with. So whether this is a volunteers based C.A. or a
> professional paying one.

Yes -- it'd mean distributing the usual set of trusted root certs
with the OS. Probably lifting /etc/ssl/cert.pem from a Unix box.

It also sucks, but it's a problem everyone else seems to have solved.



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [9front] patch smtp: ignore unrecognized certificates
  2020-07-20 15:09               ` ori
@ 2020-07-20 15:32                 ` hiro
  0 siblings, 0 replies; 21+ messages in thread
From: hiro @ 2020-07-20 15:32 UTC (permalink / raw)
  To: 9front

> a problem everyone else seems to have solved.
you call that solved?!

i think it's the opposite, as it makes it worse giving people false
sense of security.

On 7/20/20, ori@eigenstate.org <ori@eigenstate.org> wrote:
>> The problem is that if there is a chain, you need to trust the root you
>> finally end with. So whether this is a volunteers based C.A. or a
>> professional paying one.
>
> Yes -- it'd mean distributing the usual set of trusted root certs
> with the OS. Probably lifting /etc/ssl/cert.pem from a Unix box.
>
> It also sucks, but it's a problem everyone else seems to have solved.
>
>


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [9front] patch smtp: ignore unrecognized certificates
  2020-07-20 14:05   ` [9front] " ori
  2020-07-20 14:20     ` hiro
@ 2020-07-20 16:18     ` cinap_lenrek
  2020-07-20 17:16       ` Joel Fridolin Meyer
  2020-07-20 22:00       ` Steffen Nurpmeso
  1 sibling, 2 replies; 21+ messages in thread
From: cinap_lenrek @ 2020-07-20 16:18 UTC (permalink / raw)
  To: 9front

you need to differentiate some use cases.

for servers like your isp's or your networks forwarding mailserver
(machines that you have direct relation or control over), it makes
sense to pin certificates or public key. this is where you use
smtps, instead of this insecure STARTTLS contraption.

but on the internet, nobody is really checking the cert as theres no
root of trust. last time i checked, you could put a self signed cert
in your smtp server and you'd still get mail as theres not really
a common root of trust. this is different from webbrowsers where
the root of trust is controlled by the browser vendo^Wgoogle.

smtp is just opportunistic encrytion. hell, starttls can be attacked
by mitm by just stripping the command with a proxy to sabotage the
tls negotiation.

it is just best effort to at least encrypt the data, but it will not
hold against an adversary that has active mitm capability. to it
protects from passive sniffing...

mayyyybe, if we had dnssec and put the public key hash in the dns
then we could have mitm protected email transport. but its not
working very well. people whine that they dont want to trust the
dns (fair enougth) and then use letsencrypt instead which completely
100% relies on dns for the renewal...

in conclusion, it makes sense to me to add a flag to smtp client
for opportunistic encryption that skips certificate verification.
(you'd control it in your remotemail script depending on the
destination, so you can still pin the keys for sites that you
trust).

tho please dont use -c flag. its a negative, so should have
a capital letter. and we should also skip loading the tumbprint
at all, as it makes no sense to try to check anything in this case.

--
cinap


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [9front] patch smtp: ignore unrecognized certificates
  2020-07-20 16:18     ` cinap_lenrek
@ 2020-07-20 17:16       ` Joel Fridolin Meyer
  2020-07-20 22:00       ` Steffen Nurpmeso
  1 sibling, 0 replies; 21+ messages in thread
From: Joel Fridolin Meyer @ 2020-07-20 17:16 UTC (permalink / raw)
  To: 9front

Hello again.

I read through your responses and will adjust the patch (use -C instead of -c).

About no thumbprint loading: I left it in on purpose, so that admins
still get the notice and can track connections etc. For example admins
can see what connections were made and manually add them to the file
if they want to enable security checks at some point.

I can remove loading of thumbprints at all, I just wanted to give you
my thoughts.

Also we could remove the goto here, but I guess I need some hint,
because somehow my brain didn't want to think properly when I looked
at the code.

sirjofri

2020-07-20 18:18 GMT+02:00, cinap_lenrek@felloff.net <cinap_lenrek@felloff.net>:
> you need to differentiate some use cases.
>
> for servers like your isp's or your networks forwarding mailserver
> (machines that you have direct relation or control over), it makes
> sense to pin certificates or public key. this is where you use
> smtps, instead of this insecure STARTTLS contraption.
>
> but on the internet, nobody is really checking the cert as theres no
> root of trust. last time i checked, you could put a self signed cert
> in your smtp server and you'd still get mail as theres not really
> a common root of trust. this is different from webbrowsers where
> the root of trust is controlled by the browser vendo^Wgoogle.
>
> smtp is just opportunistic encrytion. hell, starttls can be attacked
> by mitm by just stripping the command with a proxy to sabotage the
> tls negotiation.
>
> it is just best effort to at least encrypt the data, but it will not
> hold against an adversary that has active mitm capability. to it
> protects from passive sniffing...
>
> mayyyybe, if we had dnssec and put the public key hash in the dns
> then we could have mitm protected email transport. but its not
> working very well. people whine that they dont want to trust the
> dns (fair enougth) and then use letsencrypt instead which completely
> 100% relies on dns for the renewal...
>
> in conclusion, it makes sense to me to add a flag to smtp client
> for opportunistic encryption that skips certificate verification.
> (you'd control it in your remotemail script depending on the
> destination, so you can still pin the keys for sites that you
> trust).
>
> tho please dont use -c flag. its a negative, so should have
> a capital letter. and we should also skip loading the tumbprint
> at all, as it makes no sense to try to check anything in this case.
>
> --
> cinap
>


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [9front] patch smtp: ignore unrecognized certificates
  2020-07-20 16:18     ` cinap_lenrek
  2020-07-20 17:16       ` Joel Fridolin Meyer
@ 2020-07-20 22:00       ` Steffen Nurpmeso
  2020-07-20 22:05         ` ori
  2020-07-20 22:07         ` ori
  1 sibling, 2 replies; 21+ messages in thread
From: Steffen Nurpmeso @ 2020-07-20 22:00 UTC (permalink / raw)
  To: 9front

cinap_lenrek@felloff.net wrote in
<BC75BC74DEF132FCD6A0F1C7E3D9FCEC@felloff.net>:
 |
 |for servers like your isp's or your networks forwarding mailserver
 |(machines that you have direct relation or control over), it makes
 |sense to pin certificates or public key. this is where you use
 |smtps, instead of this insecure STARTTLS contraption.

In November 2019 they waved through RFC 8689:

                        SMTP Require TLS Option

  Abstract

   The SMTP STARTTLS option, used in negotiating transport-level
   encryption of SMTP connections, is not as useful from a security
   standpoint as it might be because of its opportunistic nature;
   message delivery is, by default, prioritized over security.  This
   document describes an SMTP service extension, REQUIRETLS, and a
   message header field, TLS-Required.  If the REQUIRETLS option or TLS-
   Required message header field is used when sending a message, it
   asserts a request on the part of the message sender to override the
   default negotiation of TLS, either by requiring that TLS be
   negotiated when the message is relayed or by requesting that
   recipient-side policy mechanisms such as MTA-STS and DNS-Based
   Authentication of Named Entities (DANE) be ignored when relaying a
   message for which security is unimportant.

P.S.: several times i tried to contact Stanley Lieber in the past,
but never got a response.  If this mail gets through (quite some
did not in the past), would you mind changing my address to
steffen@@sdaoden.eu, please?  Thank you!!

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [9front] patch smtp: ignore unrecognized certificates
  2020-07-20 22:00       ` Steffen Nurpmeso
@ 2020-07-20 22:05         ` ori
  2020-07-20 22:19           ` Kurt H Maier
  2020-07-20 22:07         ` ori
  1 sibling, 1 reply; 21+ messages in thread
From: ori @ 2020-07-20 22:05 UTC (permalink / raw)
  To: sdaoden, 9front

> In November 2019 they waved through RFC 8689:

Nice, with luck we'll be able to turn it on by 2029 :)



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [9front] patch smtp: ignore unrecognized certificates
  2020-07-20 22:00       ` Steffen Nurpmeso
  2020-07-20 22:05         ` ori
@ 2020-07-20 22:07         ` ori
  2020-07-21 13:46           ` Steffen Nurpmeso
  1 sibling, 1 reply; 21+ messages in thread
From: ori @ 2020-07-20 22:07 UTC (permalink / raw)
  To: sdaoden, 9front

> P.S.: several times i tried to contact Stanley Lieber in the past,
> but never got a response.  If this mail gets through (quite some
> did not in the past), would you mind changing my address to
> steffen@@sdaoden.eu, please?  Thank you!!

Also -- you should be able to just resubscribe, no?



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [9front] patch smtp: ignore unrecognized certificates
  2020-07-20 22:05         ` ori
@ 2020-07-20 22:19           ` Kurt H Maier
  2020-07-21 13:02             ` Steffen Nurpmeso
  0 siblings, 1 reply; 21+ messages in thread
From: Kurt H Maier @ 2020-07-20 22:19 UTC (permalink / raw)
  To: 9front

On Mon, Jul 20, 2020 at 03:05:15PM -0700, ori@eigenstate.org wrote:
> > In November 2019 they waved through RFC 8689:
> 
> Nice, with luck we'll be able to turn it on by 2029 :)
> 

It is a failure of the IETF process that this sort of crap (which
recommends MTA-STS) is shoved through while taking extremely simple
steps like "standardizing an SMTP+TLS port" is regarded as impossible.
I suggest the current approach (manually confirming fingerprints or else
declaring them irrelevant) is superior in just about every way.

khm


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [9front] patch smtp: ignore unrecognized certificates
  2020-07-20 14:46         ` tlaronde
  2020-07-20 14:52           ` ori
@ 2020-07-21  6:55           ` cinap_lenrek
  1 sibling, 0 replies; 21+ messages in thread
From: cinap_lenrek @ 2020-07-21  6:55 UTC (permalink / raw)
  To: 9front

thats why you really want to pin the key, not the cert. this
is what we do at the moment. the thumbprint is a hash of the
public key, not the certificate. so the cert can be renewed
without changing the key.

	if(X509digestSPKI(cert, len, sha2_256, hash) < 0)
		return 0;
	if(okThumbprint(hash, SHA2_256dlen, table))
		return 1;

--
cinap


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [9front] patch smtp: ignore unrecognized certificates
  2020-07-20 22:19           ` Kurt H Maier
@ 2020-07-21 13:02             ` Steffen Nurpmeso
  0 siblings, 0 replies; 21+ messages in thread
From: Steffen Nurpmeso @ 2020-07-21 13:02 UTC (permalink / raw)
  To: 9front

Kurt H Maier wrote in
<20200720221909.GB55786@wopr>:
 |On Mon, Jul 20, 2020 at 03:05:15PM -0700, ori@eigenstate.org wrote:
 |>> In November 2019 they waved through RFC 8689:
 |> 
 |> Nice, with luck we'll be able to turn it on by 2029 :)
 |
 |It is a failure of the IETF process that this sort of crap (which
 |recommends MTA-STS) is shoved through while taking extremely simple
 |steps like "standardizing an SMTP+TLS port" is regarded as impossible.
 |I suggest the current approach (manually confirming fingerprints or else
 |declaring them irrelevant) is superior in just about every way.

Yes.  Luckily "SUBMISSIONS" on 465 is finally also standardized.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [9front] patch smtp: ignore unrecognized certificates
  2020-07-20 22:07         ` ori
@ 2020-07-21 13:46           ` Steffen Nurpmeso
  2020-07-29  7:32             ` sirjofri+ml-9front
  0 siblings, 1 reply; 21+ messages in thread
From: Steffen Nurpmeso @ 2020-07-21 13:46 UTC (permalink / raw)
  To: 9front

ori@eigenstate.org wrote in
<8ACD8978E36CCF9C48952CB2FEE6557C@eigenstate.org>:
 |> P.S.: several times i tried to contact Stanley Lieber in the past,
 |> but never got a response.  If this mail gets through (quite some
 |> did not in the past), would you mind changing my address to
 |> steffen@@sdaoden.eu, please?  Thank you!!
 |
 |Also -- you should be able to just resubscribe, no?

This seems to have worked.  (Unsubscription i do not know yet.)

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [9front] patch smtp: ignore unrecognized certificates
  2020-07-21 13:46           ` Steffen Nurpmeso
@ 2020-07-29  7:32             ` sirjofri+ml-9front
  2020-07-29  8:04               ` hiro
  2020-08-01 10:01               ` cinap_lenrek
  0 siblings, 2 replies; 21+ messages in thread
From: sirjofri+ml-9front @ 2020-07-29  7:32 UTC (permalink / raw)
  To: 9front

[-- Attachment #1: Type: text/plain, Size: 219 bytes --]

Hey all,

I prepared a better patch, this time including a line in the man page and an adjusted usage line. Also this time I don't do the certificate checks, all certs are ignored. This also changes -c to -C.

sirjofri

[-- Attachment #2: Type: text/plain, Size: 1699 bytes --]

diff -r 639ad985a75b sys/man/8/smtp
--- a/sys/man/8/smtp	Mon Jul 20 18:58:52 2020 -0700
+++ b/sys/man/8/smtp	Wed Jul 29 09:24:42 2020 +0200
@@ -6,7 +6,7 @@
 .ti -0.5i
 .B upas/smtp
 [
-.B -aAdfipst
+.B -aACdfipst
 ] [
 .B -b
 .I busted-mx
@@ -81,6 +81,9 @@
 when trying MX hosts.
 May be repeated.
 .TP
+.B -C
+ignore bad thumbprints for TLS connections.
+.TP
 .B -d
 turn on debugging to standard error.
 .TP
diff -r 639ad985a75b sys/src/cmd/upas/smtp/smtp.c
--- a/sys/src/cmd/upas/smtp/smtp.c	Mon Jul 20 18:58:52 2020 -0700
+++ b/sys/src/cmd/upas/smtp/smtp.c	Wed Jul 29 09:24:42 2020 +0200
@@ -46,6 +46,7 @@
 int	quitting;	/* when error occurs in quit */
 int	tryauth;	/* Try to authenticate, if supported */
 int	trysecure;	/* Try to use TLS if the other side supports it */
+int	nocertcheck; /* ignore unrecognized certs. Still logged */
 
 char	*quitrv;	/* deferred return value when in quit */
 char	ddomain[1024];	/* domain name of destination machine */
@@ -85,7 +86,7 @@
 void
 usage(void)
 {
-	fprint(2, "usage: smtp [-aAdfipst] [-b busted-mx] [-g gw] [-h host] "
+	fprint(2, "usage: smtp [-aACdfipst] [-b busted-mx] [-g gw] [-h host] "
 		"[-u user] [.domain] net!host[!service] sender rcpt-list\n");
 	exits(Giveup);
 }
@@ -185,6 +186,9 @@
 	case 'u':
 		user = EARGF(usage());
 		break;
+	case 'C':
+		nocertcheck = 1;
+		break;
 	default:
 		usage();
 		break;
@@ -413,6 +417,12 @@
 	Bterm(&bin);
 	Binit(&bin, fd, OREAD);
 
+	if (nocertcheck) {
+		syslog(0, "smtp", "ignoring cert for %s", ddomain);
+		err = nil;
+		goto Out;
+	}
+
 	goodcerts = initThumbprints(smtpthumbs, smtpexclthumbs, "x509");
 	if (goodcerts == nil) {
 		syslog(0, "smtp", "bad thumbprints in %s", smtpthumbs);

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [9front] patch smtp: ignore unrecognized certificates
  2020-07-29  7:32             ` sirjofri+ml-9front
@ 2020-07-29  8:04               ` hiro
  2020-08-01 10:01               ` cinap_lenrek
  1 sibling, 0 replies; 21+ messages in thread
From: hiro @ 2020-07-29  8:04 UTC (permalink / raw)
  To: 9front

you see no risk the syslog gets spammed too much with this? it would
happen for nearly every mail, no?


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [9front] patch smtp: ignore unrecognized certificates
  2020-07-29  7:32             ` sirjofri+ml-9front
  2020-07-29  8:04               ` hiro
@ 2020-08-01 10:01               ` cinap_lenrek
  1 sibling, 0 replies; 21+ messages in thread
From: cinap_lenrek @ 2020-08-01 10:01 UTC (permalink / raw)
  To: 9front

good, except i dont think theres a point in logging when we explicitely
disabled the cert check.

--
cinap


^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2020-08-01 10:01 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <aee5c8d2-ef2b-4ef2-8594-e6786cbd6e2e@sirjofri.de>
2020-07-19  9:43 ` patch smtp: ignore unrecognized certificates Joel Fridolin Meyer
2020-07-20 14:05   ` [9front] " ori
2020-07-20 14:20     ` hiro
2020-07-20 14:26       ` ori
2020-07-20 14:46         ` tlaronde
2020-07-20 14:52           ` ori
2020-07-20 15:05             ` tlaronde
2020-07-20 15:09               ` ori
2020-07-20 15:32                 ` hiro
2020-07-21  6:55           ` cinap_lenrek
2020-07-20 16:18     ` cinap_lenrek
2020-07-20 17:16       ` Joel Fridolin Meyer
2020-07-20 22:00       ` Steffen Nurpmeso
2020-07-20 22:05         ` ori
2020-07-20 22:19           ` Kurt H Maier
2020-07-21 13:02             ` Steffen Nurpmeso
2020-07-20 22:07         ` ori
2020-07-21 13:46           ` Steffen Nurpmeso
2020-07-29  7:32             ` sirjofri+ml-9front
2020-07-29  8:04               ` hiro
2020-08-01 10:01               ` cinap_lenrek

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).