[9front] "Insecure" icon in gmail

[9front] "Insecure" icon in gmail

[Dave MacFarlane]

I just spent more time than I care to admit trying 
to get rid of the red "Insecure" icon on emails sent 
to gmail from my 9front box. 
 
In the end, the meat of my /mail/lib/remotemail ended up 
being 
	exec /bin/upas/dkim -s 20180128 -d driusan.net >[2]/sys/log/dkim| /bin/upas/smtp -s -h driusan.net .driusan.net $addr $sender $* 
 
But I had to modify upas/smtp to *not* validate the certificate 
for startls by commenting out the okCertificate line in  
/sys/src/cmd/upas/smtp/smtp.c 
 
This doesn't seem like a great idea, but without -s remotemail 
won't use startls, and with -s the list of thumbs needs to be 
maintained for every email server on the internet in order to 
send email as far as I can tell. 
 
So I have 3 questions: 
1. Am I missing something obvious? 
2. Is there a better way to do this? 
3. Would it make sense to add a flag to use startls but not validate certificates for upas/smtp? 
 
- Dave 

Re: [9front] "Insecure" icon in gmail

[Stanley Lieber]

On May 15, 2024 5:21:33 PM EDT, Dave MacFarlane <driusan@driusan.net> wrote:
>I just spent more time than I care to admit trying
>to get rid of the red "Insecure" icon on emails sent
>to gmail from my 9front box.
>
>In the end, the meat of my /mail/lib/remotemail ended up
>being
>	exec /bin/upas/dkim -s 20180128 -d driusan.net >[2]/sys/log/dkim| /bin/upas/smtp -s -h driusan.net .driusan.net $addr $sender $*
>
>But I had to modify upas/smtp to *not* validate the certificate
>for startls by commenting out the okCertificate line in 
>/sys/src/cmd/upas/smtp/smtp.c
>
>This doesn't seem like a great idea, but without -s remotemail
>won't use startls, and with -s the list of thumbs needs to be
>maintained for every email server on the internet in order to
>send email as far as I can tell.
>
>So I have 3 questions:
>1. Am I missing something obvious?
>2. Is there a better way to do this?
>3. Would it make sense to add a flag to use startls but not validate certificates for upas/smtp?
>
>- Dave
>

coincidentally, i'm getting ready to setup dkim. i'd welcome any learned discussion on this topic. once i get something working i will document it in the fqa.

sl

[9front] Re: "Insecure" icon in gmail

[Anthony Martin]

Dave MacFarlane <driusan@driusan.net> once said:
> 1. Am I missing something obvious?

Nope. The thumbprint(6) style PKI system is simpler but more
tedious compared to the certificate authority system if you're
interacting with a lot of foreign servers that you don't personally
trust but still want to set up a "secure" channel with them. You
have to go with something like the CA system for third party
verification or raw dog it with a trust on first use policy.

> 2. Is there a better way to do this?

Not currently. Note that webfs, ftpfs, aux/wpa, dns over tls, and
probably others do not bother checking the validity of a server's
certificate. This is not ideal. No one has done the work. Alas.

> 3. Would it make sense to add a flag to use startls but not
> validate certificates for upas/smtp?

Perhaps. But it would still be "insecure" even if the Google borg
doesn't show the super serious (see, it's even colored red) flag
on your messages.

Cheers,
  Anthony

Re: [9front] Re: "Insecure" icon in gmail

[Kurt H Maier]

On Wed, May 15, 2024 at 06:23:05PM -0700, Anthony Martin wrote:
> 
> Not currently. Note that webfs, ftpfs, aux/wpa, dns over tls, and
> probably others do not bother checking the validity of a server's
> certificate. This is not ideal. No one has done the work. Alas.
> 

I'm not sure how much benefit there is to cert validation, since the
current Browser/CA forum is just "whatever Google wants" and there's
only meaningful enforcement against bad CAs about once per decade.  TOFU
is as good as anything else, since there's nobody trustworthy to
whom to outsource any of this.

As should have been obvious to the internet forefathers, conflating
integrity, authorization, and authentication turns out to be a bad idea.
Consider TLS to be opportunistic line encryption; if you want to secure
the contents of the messages, sign or encrypt them, and get your public
keys to the recipient on some other channel.


khm

Re: [9front] Re: "Insecure" icon in gmail

[Dave MacFarlane]

On May 15, 2024 9:23:05 p.m. EDT, Anthony Martin <ality@pbrane.org> wrote:
>Dave MacFarlane <driusan@driusan.net> once said:
>> 2. Is there a better way to do this?
>
>Not currently. Note that webfs, ftpfs, aux/wpa, dns over tls, and
>probably others do not bother checking the validity of a server's
>certificate. This is not ideal. No one has done the work. Alas.
>
>> 3. Would it make sense to add a flag to use startls but not
>> validate certificates for upas/smtp?
>
>Perhaps. But it would still be "insecure" even if the Google borg
>doesn't show the super serious (see, it's even colored red) flag
>on your messages.
>
>Cheers,
>  Anthony
>

I'm not sure I follow why it would be more insecure than the things you listed above. 

Currently the options I can figure out with the flags to upas/smtp are: 
1. Transmitted in plain text
2. Encrypted in transit, but you can only send email to known servers that you've pre-setup the thumbprint for before sending.

The security would be between the two.

Re: [9front] Re: "Insecure" icon in gmail

[Anthony Martin]

Dave MacFarlane <driusan@driusan.net> once said:
> I'm not sure I follow why it would be more insecure than the things you
> listed above.
>
> Currently the options I can figure out with the flags to upas/smtp are:
> 1. Transmitted in plain text
> 2. Encrypted in transit, but you can only send email to known servers
> that you've pre-setup the thumbprint for before sending.
>
> The security would be between the two.

We're in agreement. I was only poking fun at the absurdity. When
your server connects to them, they don't validate a client certificate
and you're not going to validate the server certifcate but the message
will still be marked "secure". I find it funny.

(Yeah, I know: spf, dkim, dmarc, blah, blah, blah. Still ...)

Cheers,
  Anthony

Re: [9front] "Insecure" icon in gmail

[cinap_lenrek]

> 3. Would it make sense to add a flag to use startls but not validate certificates for upas/smtp?

yes. i think that makes sense. Maybe "-C" as in disable thumbprint/certificate check?

--
cinap

Re: [9front] "Insecure" icon in gmail

[sirjofri]

16.05.2024 12:28:35 cinap_lenrek@felloff.net:

>> 3. Would it make sense to add a flag to use startls but not validate certificates for upas/smtp?
>
> yes. i think that makes sense. Maybe "-C" as in disable thumbprint/certificate check?

Pretty sure I have a patch for exactly that somewhere...

http://sirjofri.de/oat/patches/smtp.patch

Re: [9front] "Insecure" icon in gmail

[ori]

on one hand, I don't like doing it, on the other hand... I guess
we don't have much of a better option. ugh.

committed.

Quoth sirjofri <sirjofri+ml-9front@sirjofri.de>:
> 16.05.2024 12:28:35 cinap_lenrek@felloff.net:
> 
> >> 3. Would it make sense to add a flag to use startls but not validate certificates for upas/smtp?
> >
> > yes. i think that makes sense. Maybe "-C" as in disable thumbprint/certificate check?
> 
> Pretty sure I have a patch for exactly that somewhere...
> 
> http://sirjofri.de/oat/patches/smtp.patch
> 

Re: [9front] "Insecure" icon in gmail

[hiro]

+        syslog(0, "smtp", "ignoring cert for %s", ddomain);
then i guess, debugging is off on the mailserver?

On Sat, May 18, 2024 at 9:41 PM <ori@eigenstate.org> wrote:
>
> on one hand, I don't like doing it, on the other hand... I guess
> we don't have much of a better option. ugh.
>
> committed.
>
> Quoth sirjofri <sirjofri+ml-9front@sirjofri.de>:
> > 16.05.2024 12:28:35 cinap_lenrek@felloff.net:
> >
> > >> 3. Would it make sense to add a flag to use startls but not validate certificates for upas/smtp?
> > >
> > > yes. i think that makes sense. Maybe "-C" as in disable thumbprint/certificate check?
> >
> > Pretty sure I have a patch for exactly that somewhere...
> >
> > http://sirjofri.de/oat/patches/smtp.patch
> >
>

Re: [9front] "Insecure" icon in gmail

[sirjofri]

18.05.2024 22:14:37 hiro <23hiro@gmail.com>:

> +        syslog(0, "smtp", "ignoring cert for %s", ddomain);
> then i guess, debugging is off on the mailserver?

Back then, I more or less copied the syslog stuff from the other parts of the code (see about 5 lines below that).

I was also thinking about implementing trust-on-first-use, but that would be a bigger change. For me, -C was enough. I've been running this code for a few years now.