* [9front] "Insecure" icon in gmail
@ 2024-05-15 21:21 Dave MacFarlane
2024-05-15 21:28 ` Stanley Lieber
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Dave MacFarlane @ 2024-05-15 21:21 UTC (permalink / raw)
To: 9front
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9front] "Insecure" icon in gmail
2024-05-15 21:21 [9front] "Insecure" icon in gmail Dave MacFarlane
@ 2024-05-15 21:28 ` Stanley Lieber
2024-05-16 1:23 ` [9front] " Anthony Martin
2024-05-16 10:27 ` [9front] " cinap_lenrek
2 siblings, 0 replies; 11+ messages in thread
From: Stanley Lieber @ 2024-05-15 21:28 UTC (permalink / raw)
To: 9front
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* [9front] Re: "Insecure" icon in gmail
2024-05-15 21:21 [9front] "Insecure" icon in gmail Dave MacFarlane
2024-05-15 21:28 ` Stanley Lieber
@ 2024-05-16 1:23 ` Anthony Martin
2024-05-16 1:39 ` Kurt H Maier
2024-05-16 2:06 ` Dave MacFarlane
2024-05-16 10:27 ` [9front] " cinap_lenrek
2 siblings, 2 replies; 11+ messages in thread
From: Anthony Martin @ 2024-05-16 1:23 UTC (permalink / raw)
To: 9front
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9front] Re: "Insecure" icon in gmail
2024-05-16 1:23 ` [9front] " Anthony Martin
@ 2024-05-16 1:39 ` Kurt H Maier
2024-05-16 2:06 ` Dave MacFarlane
1 sibling, 0 replies; 11+ messages in thread
From: Kurt H Maier @ 2024-05-16 1:39 UTC (permalink / raw)
To: 9front
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9front] Re: "Insecure" icon in gmail
2024-05-16 1:23 ` [9front] " Anthony Martin
2024-05-16 1:39 ` Kurt H Maier
@ 2024-05-16 2:06 ` Dave MacFarlane
2024-05-16 2:51 ` Anthony Martin
1 sibling, 1 reply; 11+ messages in thread
From: Dave MacFarlane @ 2024-05-16 2:06 UTC (permalink / raw)
To: 9front
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9front] Re: "Insecure" icon in gmail
2024-05-16 2:06 ` Dave MacFarlane
@ 2024-05-16 2:51 ` Anthony Martin
0 siblings, 0 replies; 11+ messages in thread
From: Anthony Martin @ 2024-05-16 2:51 UTC (permalink / raw)
To: 9front
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9front] "Insecure" icon in gmail
2024-05-15 21:21 [9front] "Insecure" icon in gmail Dave MacFarlane
2024-05-15 21:28 ` Stanley Lieber
2024-05-16 1:23 ` [9front] " Anthony Martin
@ 2024-05-16 10:27 ` cinap_lenrek
2024-05-16 11:01 ` sirjofri
2 siblings, 1 reply; 11+ messages in thread
From: cinap_lenrek @ 2024-05-16 10:27 UTC (permalink / raw)
To: 9front
> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9front] "Insecure" icon in gmail
2024-05-16 10:27 ` [9front] " cinap_lenrek
@ 2024-05-16 11:01 ` sirjofri
2024-05-18 18:45 ` ori
0 siblings, 1 reply; 11+ messages in thread
From: sirjofri @ 2024-05-16 11:01 UTC (permalink / raw)
To: 9front
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9front] "Insecure" icon in gmail
2024-05-16 11:01 ` sirjofri
@ 2024-05-18 18:45 ` ori
2024-05-18 20:12 ` hiro
0 siblings, 1 reply; 11+ messages in thread
From: ori @ 2024-05-18 18:45 UTC (permalink / raw)
To: 9front
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
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9front] "Insecure" icon in gmail
2024-05-18 18:45 ` ori
@ 2024-05-18 20:12 ` hiro
2024-05-18 22:27 ` sirjofri
0 siblings, 1 reply; 11+ messages in thread
From: hiro @ 2024-05-18 20:12 UTC (permalink / raw)
To: 9front
+ 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
> >
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9front] "Insecure" icon in gmail
2024-05-18 20:12 ` hiro
@ 2024-05-18 22:27 ` sirjofri
0 siblings, 0 replies; 11+ messages in thread
From: sirjofri @ 2024-05-18 22:27 UTC (permalink / raw)
To: 9front
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2024-05-18 22:29 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-05-15 21:21 [9front] "Insecure" icon in gmail Dave MacFarlane
2024-05-15 21:28 ` Stanley Lieber
2024-05-16 1:23 ` [9front] " Anthony Martin
2024-05-16 1:39 ` Kurt H Maier
2024-05-16 2:06 ` Dave MacFarlane
2024-05-16 2:51 ` Anthony Martin
2024-05-16 10:27 ` [9front] " cinap_lenrek
2024-05-16 11:01 ` sirjofri
2024-05-18 18:45 ` ori
2024-05-18 20:12 ` hiro
2024-05-18 22:27 ` sirjofri
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).