OpenSMTPD 6.7.0 without TLS SNI as client while MTA delivering emails
>Synopsis: mta server-cert-check result="failure" - no TLS SNI while >delivering emails >Category: user >Environment: System : OpenBSD 6.7 Details : OpenBSD 6.7-current (GENERIC.MP) #223: Wed May 27 00:35:01 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: I was sending an email from one OpenBSD machine to another, both running OpenSMTPD. Sending machine (STARTTLS client) runs -current. This bug report is generated on machine sending an SMTP message. Receiving machine runs OpenBSD 6.7-stable. Sending machine: pce-0014# grep -F 7aac28a89880ff0d /var/log/maillog 2020-05-29T04:39:51.452Z pce-0014 smtpd[59601]: 7aac28a89880ff0d mta connecting address=smtp://91.121.99.69:25 host=kimsufi.nodegroup.io 2020-05-29T04:39:51.486Z pce-0014 smtpd[59601]: 7aac28a89880ff0d mta connected 2020-05-29T04:39:51.838Z pce-0014 smtpd[59601]: 7aac28a89880ff0d mta tls ciphers=TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256 2020-05-29T04:39:52.051Z pce-0014 smtpd[59601]: 7aac28a89880ff0d mta ssl_check_name: no match for 'ks1.nodegroup.io' in cert 2020-05-29T04:39:52.051Z pce-0014 smtpd[59601]: 7aac28a89880ff0d mta server-cert-check result="failure" 2020-05-29T04:39:52.538Z pce-0014 smtpd[59601]: 7aac28a89880ff0d mta delivery evpid=f8e40666dbcc4579 from= to= rcpt=<-> source="192.168.221.14" relay="91.121.99.69 (kimsufi.nodegroup.io)" delay=1s result="Ok" stat="250 2.0.0 143e5fb9 Message accepted for delivery" 2020-05-29T04:40:02.666Z pce-0014 smtpd[59601]: 7aac28a89880ff0d mta disconnected reason=quit messages=1 Receiving machine: ks1# grep -F f07800b4ebe13f5f /var/log/maillog 2020-05-29T04:39:51.502Z ks28975 smtpd[23473]: f07800b4ebe13f5f smtp connected address=46.187.204.8 host=dhcp46-187-204-8.eaw.com.pl 2020-05-29T04:39:51.640Z ks28975 smtpd[6847]: dnsbl: f07800b4ebe13f5f not listed 2020-05-29T04:39:51.817Z ks28975 smtpd[23473]: f07800b4ebe13f5f smtp tls ciphers=TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256 2020-05-29T04:39:52.517Z ks28975 smtpd[23473]: f07800b4ebe13f5f smtp message msgid=143e5fb9 size=928 nrcpt=1 proto=ESMTP 2020-05-29T04:39:52.517Z ks28975 smtpd[23473]: f07800b4ebe13f5f smtp envelope evpid=143e5fb973bcfc39 from= to= 2020-05-29T04:40:02.646Z ks28975 smtpd[23473]: f07800b4ebe13f5f smtp disconnected reason=quit I was surprised to see that smtpd acting as TLS client reports: mta ssl_check_name: no match for 'ks1.nodegroup.io' in cert mta server-cert-check result="failure" as my smtpd.conf has PKI configured for 'ks1.nodegroup.io' domain: ks1# grep -w pki /etc/mail/smtpd.conf | grep -F nodegroup.io pki "kimsufi.nodegroup.io" dhe auto pki "kimsufi.nodegroup.io" key "/etc/mail/certs/kimsufi.nodegroup.io.key" pki "kimsufi.nodegroup.io" cert "/etc/mail/certs/kimsufi.nodegroup.io.crt" pki "ks1.nodegroup.io" dhe auto pki "ks1.nodegroup.io" key "/etc/mail/certs/ks1.nodegroup.io.key" pki "ks1.nodegroup.io" cert "/etc/mail/certs/ks1.nodegroup.io-full.crt" I checked with openssl command that SNI on the smtpd server works and it seems to work: Without SNI: $ openssl s_client -connect ks1.nodegroup.io:25 -starttls smtp 2>/dev/null /dev/null How-To-Repeat: Two OpenBSD machine, one sending an email runs OpenSMTPD -current. Receiving OpenBSD machine with OpenSMTPD running and more than one PKI domain configured. Send an email to non-default TLS domain on the smtpd server: $ echo "this is test $RANDOM" | mail -s "Random test $RANDOM" test95289...@ks1.nodegroup.io Above will result with `mta server-cert-check result="failure"` in mail logs. However sending an email to default TLS domain on the smtpd server: $ echo "this is test $RANDOM" | mail -s "Random test $RANDOM" test95289...@kimsufi.nodegroup.io Shows `mta server-cert-check result="success"`: pce-0014# grep -F d0bd44a56ad4e669 /var/log/maillog 2020-05-29T05:13:00.413Z pce-0014 smtpd[14183]: d0bd44a56ad4e669 mta connecting address=smtp://91.121.99.69:25 host=kimsufi.nodegroup.io 2020-05-29T05:13:00.449Z pce-0014 smtpd[14183]: d0bd44a56ad4e669 mta connected 2020-05-29T05:13:00.718Z pce-0014 smtpd[14183]: d0bd44a56ad4e669 mta tls ciphers=TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256 2020-05-29T05:13:00.947Z pce-0014 smtpd[14183]: d0bd44a56ad4e669 mta server-cert-check result="success" 2020-05-29T05:13:01.546Z pce-0014 smtpd[14183]: d0bd44a56ad4e669 mta delivery evpid=191738ce54ce53f1 from= to= rcpt=<-> source="192.168.221.14" relay="91.121.99.69 (kimsufi.nodegroup.io)" delay=1s result="Ok" stat="250 2.0.0 47993b17 Message accepted for delivery" 2020-05-29T05:13:11.683Z pce-0014 smtpd[14183]: d0bd44a56ad4e669 mta disconnected reason=quit messages=1 >Fix: No diff, sorry :/ dmesg: OpenBSD 6.7-current (GENERIC.MP) #223: Wed May 27 00:35:01 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4259995648 (4062
Re: athn panic ieee80211_encrypt: key unset for sw crypto: 0 on May 24 2020 generic.mp
On Wed, May 27, 2020 at 07:54:32AM +, Mikolaj Kucharski wrote:
> On Wed, May 27, 2020 at 09:31:00AM +0200, Stefan Sperling wrote:
> > > Uptime of 3h37m with following two entries (from dmesg):
> >
> > So this uptime is a lot better than what you saw before?
>
> I actually cannot compare is it better or not. This PC Engines machine
> runs -current and I upgrade it very regularly. Uptime below a week is
> normnal. Uptime of 30+ days would be probably because I'm traveling and
> I don't want to do remote upgrades. With COVID-19 I'm not really
> traveling these days, so no long uptimes for that box.
At the time of writing this email access point has 36 hrs of uptime and
I was not able to trigger kernel panic, nor XXX messages showed up in
dmesg with the latest version of the diff (int rekeysta = 0).
As I cannot repro the panic, I guess for now I don't have anything more
to add to this thread, except that your diff works, Stefan.
I can trigger athn device timeouts, but this looks like a different
issue, so I may start new thread about it, but for now I need to think
how to collect anything useful for this problem, because except dmesg
messages I don't have anything else about the problem.
> > The patch I sent had a small bug. It added an uninitialized variable at
> > the top ieee80211_setkeys(). Please change:
> >
> > int rekeysta;
> >
> > to this:
> >
> > int rekeysta = 0;
>
> Sure will recompile and run new kernel again, with my printf().
>
>
> > As in shown in this new patch.
> >
> > diff fb4b0a9b3955c9a65ddbc22c472ac0e5fb216ac6 /usr/src
> > blob - b44405af41448849059a4558c55bd182f823c1df
> > file + sys/net80211/ieee80211_proto.c
> > --- sys/net80211/ieee80211_proto.c
> > +++ sys/net80211/ieee80211_proto.c
> > @@ -433,6 +433,7 @@ ieee80211_setkeys(struct ieee80211com *ic)
> > {
> > struct ieee80211_key *k;
> > u_int8_t kid;
> > + int rekeysta = 0;
> >
> > /* Swap(GM, GN) */
> > kid = (ic->ic_def_txkey == 1) ? 2 : 1;
> > @@ -457,6 +458,9 @@ ieee80211_setkeys(struct ieee80211com *ic)
> > }
> >
> > ieee80211_iterate_nodes(ic, ieee80211_node_gtk_rekey, ic);
> > + ieee80211_iterate_nodes(ic, ieee80211_count_rekeysta, &rekeysta);
> > + if (rekeysta == 0)
> > + ieee80211_setkeysdone(ic);
> > }
> >
> > /*
> > @@ -466,6 +470,12 @@ void
> > ieee80211_setkeysdone(struct ieee80211com *ic)
> > {
> > u_int8_t kid;
> > +
> > + /*
> > +* Discard frames buffered for power-saving which were encrypted with
> > +* the old group key. Clients are no longer able to decrypt them.
> > +*/
> > + mq_purge(&ic->ic_bss->ni_savedq);
> >
> > /* install GTK */
> > kid = (ic->ic_def_txkey == 1) ? 2 : 1;
>
--
Regards,
Mikolaj
Sample Zabbix httpd configuration not working
System: OpenBSD 6.7 Description: The sample httpd configuration in /usr/local/share/doc/pkg-readmes/zabbix-web has a syntax error. How-To-Repeat: # pkg_add zabbix-web # rcctl enable httpd # rcctl -d start httpd /etc/httpd.conf:2: syntax error Fix: Replace line 2 from: listen on * 80 To: listen on * port 80
Re: X hangs
On Thu, May 28, 2020 at 01:41:43PM +0100, Stuart Henderson wrote:
> No idea if related to the hangs I saw earlier, but I've just hit a
> uaudio-related kernel crash when starting to play a video in firefox.
>
> RA\xaf\xdeRA\xaf\xdeRA\xaf\xdeRA\xaf\xdeRA\xaf\xdeRA\xaf\xdeRA\xaf\xde: can't
> set interface
> kernel: protection fault trap, code=0
> Stopped at uaudio_stream_close+0x8a: movzbl 0x8(%r12),%esi
> ddb{3}> [-- sthen@localhost attached -- Thu May 28 11:58:19 2020]
>
> Note that RA\xaf\xde is 52 41 af de; case 3 of poison_value() in
> kern/subr_poison.c
> gives us
>
> $ echo '(POISON1 & 0x) | (~POISON1 & 0x)' | sed
> s/POISON1/0xdeafbead/g | moo
> 0xdeaf4152
>
> (aren't you glad this is serial console not screenshots :)
Indeed.
> uaudio0 at uhub7 port 2 configuration 1 interface 1 "GN Netcom GN 9350" rev
> 2.00/1.00 addr 7
> uaudio0: class v1, full-speed, sync, channels: 1 play, 1 rec, 4 ctls
> audio1 at uaudio0
> uhidev0 at uhub7 port 2 configuration 1 interface 3 "GN Netcom GN 9350" rev
> 2.00/1.00 addr 7
> uhidev0: iclass 3/0
> uhid0 at uhidev0: input=2, output=2, feature=0
> uaudio0: can't reset interface
> uaudio0: can't reset interface
> audio1 detached
> uaudio0 detached
> uhid0 detached
> uhidev0 detached
> RA\xaf\xdeRA\xaf\xdeRA\xaf\xdeRA\xaf\xdeRA\xaf\xdeRA\xaf\xdeRA\xaf\xde: can't
> set interface
> kernel: protection fault trap, code=0
> Stopped at uaudio_stream_close+0x8a: movzbl 0x8(%r12),%esi
> ddb{3}> [-- sthen@localhost attached -- Thu May 28 11:58:19 2020]
>
> ddb{3}>
> ddb{3}> tr
> uaudio_stream_close(81dfb000,1) at uaudio_stream_close+0x8a
> uaudio_stream_open(81dfb000,1,801e8000,801eaa80,2a8,816f7630)
> at uaudio_stream_open+0x761
> uaudio_trigger_output(81dfb000,801e8000,801eaa80,2a8,816f7630,81e95c00)
> at uaudio_trigger_output+0x47
> audio_start_do(81e95c00) at audio_start_do+0xb5
> audioioctl(2a01,20004126,800035a74470,7,800034fe6750) at
> audioioctl+0x71
> VOP_IOCTL(fd867a72e9e0,20004126,800035a74470,7,fd84fea6f9c0,800034fe6750)
> at VOP_IOCTL+0x55
> vn_ioctl(fd867d490f10,20004126,800035a74470,800034fe6750) at
> vn_ioctl+0x75
> sys_ioctl(800034fe6750,800035a74580,800035a745e0) at
> sys_ioctl+0x2df
> syscall(800035a74650) at syscall+0x389
> Xsyscall() at Xsyscall+0x128
> end of kernel
I think the above happened because the audio device was not fully
drained of users before it got destroyed. Possibly uaudio_stream_open()
got blocked and then the device was detached. Once uaudio_stream_open()
resumed, the device was gone.
Unfortunately, the kernel has no unified way to do the draining. Maybe
uaudio(4) could adopt more of the tricks that some other USB device
drivers use to manage with detaching devices.
Re: X hangs
No idea if related to the hangs I saw earlier, but I've just hit a
uaudio-related kernel crash when starting to play a video in firefox.
RA\xaf\xdeRA\xaf\xdeRA\xaf\xdeRA\xaf\xdeRA\xaf\xdeRA\xaf\xdeRA\xaf\xde: can't
set interface
kernel: protection fault trap, code=0
Stopped at uaudio_stream_close+0x8a: movzbl 0x8(%r12),%esi
ddb{3}> [-- sthen@localhost attached -- Thu May 28 11:58:19 2020]
Note that RA\xaf\xde is 52 41 af de; case 3 of poison_value() in
kern/subr_poison.c
gives us
$ echo '(POISON1 & 0x) | (~POISON1 & 0x)' | sed
s/POISON1/0xdeafbead/g | moo
0xdeaf4152
(aren't you glad this is serial console not screenshots :)
[-- MARK -- Thu May 28 11:00:00 2020]
audio1 detached
uaudio0 detached
uhid0 detached
uhidev0 detached
uaudio0 at uhub7 port 2 configuration 1 interface 1 "GN Netcom GN 9350" rev
2.00/1.00 addr 7
uaudio0: class v1, full-speed, sync, channels: 1 play, 1 rec, 4 ctls
audio1 at uaudio0
uhidev0 at uhub7 port 2 configuration 1 interface 3 "GN Netcom GN 9350" rev
2.00/1.00 addr 7
uhidev0: iclass 3/0
uhid0 at uhidev0: input=2, output=2, feature=0
audio1 detached
uaudio0 detached
uhid0 detached
uhidev0 detached
uaudio0 at uhub7 port 2 configuration 1 interface 1 "GN Netcom GN 9350" rev
2.00/1.00 addr 7
uaudio0: failed to get ranges for level control
uaudio0: failed to get ranges for level control
uaudio0: class v1, full-speed, sync, channels: 1 play, 1 rec, 2 ctls
audio1 at uaudio0
uhidev0 at uhub7 port 2 configuration 1 interface 3 "GN Netcom GN 9350" rev
2.00/1.00 addr 7
uhidev0: no report descriptor
audio1 detached
uaudio0 detached
uhidev0 detached
uaudio0 at uhub7 port 2 configuration 1 interface 1 "GN Netcom GN 9350" rev
2.00/1.00 addr 7
uaudio0: class v1, full-speed, sync, channels: 1 play, 1 rec, 4 ctls
audio1 at uaudio0
uhidev0 at uhub7 port 2 configuration 1 interface 3 "GN Netcom GN 9350" rev
2.00/1.00 addr 7
uhidev0: iclass 3/0
uhid0 at uhidev0: input=2, output=2, feature=0
uaudio0: can't reset interface
uaudio0: can't reset interface
audio1 detached
uaudio0 detached
uhid0 detached
uhidev0 detached
RA\xaf\xdeRA\xaf\xdeRA\xaf\xdeRA\xaf\xdeRA\xaf\xdeRA\xaf\xdeRA\xaf\xde: can't
set interface
kernel: protection fault trap, code=0
Stopped at uaudio_stream_close+0x8a: movzbl 0x8(%r12),%esi
ddb{3}> [-- sthen@localhost attached -- Thu May 28 11:58:19 2020]
ddb{3}>
ddb{3}> tr
uaudio_stream_close(81dfb000,1) at uaudio_stream_close+0x8a
uaudio_stream_open(81dfb000,1,801e8000,801eaa80,2a8,816f7630)
at uaudio_stream_open+0x761
uaudio_trigger_output(81dfb000,801e8000,801eaa80,2a8,816f7630,81e95c00)
at uaudio_trigger_output+0x47
audio_start_do(81e95c00) at audio_start_do+0xb5
audioioctl(2a01,20004126,800035a74470,7,800034fe6750) at audioioctl+0x71
VOP_IOCTL(fd867a72e9e0,20004126,800035a74470,7,fd84fea6f9c0,800034fe6750)
at VOP_IOCTL+0x55
vn_ioctl(fd867d490f10,20004126,800035a74470,800034fe6750) at
vn_ioctl+0x75
sys_ioctl(800034fe6750,800035a74580,800035a745e0) at sys_ioctl+0x2df
syscall(800035a74650) at syscall+0x389
Xsyscall() at Xsyscall+0x128
end of kernel
end trace frame: 0x7f7f4b50, count: -10
ddb{3}> ps
PID TID PPIDUID S FLAGS WAIT COMMAND
81832 329115 63766755 2 0x2snmpbulkwalk
29247 373389 18746755 2 0x2snmpbulkwalk
92787 86486785667 30x1000b2 poll ping
785 117710 43947667 30x82 piperdcheck_ping
67767 195190 80498755 2 0x2snmpget
49602 108618 76493755 30x82 selectsnmpgetnext
79359 286268 48050667 30x1000b2 poll ping
28903 141903 72867667 30x1000b2 poll ping
13991 135834 21132667 30x1000b2 poll ping
21132 104090 43947667 30x82 piperdcheck_ping
48050 266973 43947667 30x82 piperdcheck_ping
72867 121151 43947667 30x82 piperdcheck_ping
19194 27887 39235667 30x1000b2 poll ping6
39235 146853 43947667 30x82 piperdcheck_ping
90145 177522 43545667 30x1000b2 poll ping
43545 424834 43947667 30x82 piperdcheck_ping
77995 496911 25446667 30x1000b2 poll ping
25446 446626 43947667 30x82 piperdcheck_ping
1021 516780 38791667 30x1000b2 poll ping
38791 392276 43947667 30x82 piperdcheck_ping
63506 75846 85416732 30x200042 netlock mongod
63506 259264 85416732 3 0x420008a sigwait mongod
63506 192300 85416732 3 0x4200082 fsleepmongod
63506 398131 85416732 3 0x4200082 nanosleep mongod
63506 100766 85416732 3
Re: iwm: Intel Wireless AC 3160 fails to connect to access point
On Thu, May 28, 2020 at 04:40:43AM -0700, Brandon Sahlin wrote: > After some trial and error, I found the problem. My rather crufty > /etc/hostname.iwm0 file set the mode to 11n. This worked with > OpenBSD 6.6 with the problematic access point, but not with OpenBSD 6.7. > Commenting out the mode line let the interface card conect in 11g mode. > > The odd thing is that having the mode set to 11n worked with one access > point (iphone 8), giving a reported 11n connection in ifconfig, but > fails to complete the handshake with the problematic access point. Interesting. For further analysis would be useful to have copies of the frames exchanged during association. You can capture these frames by letting the following command run while iwm0 moves from down state to UP and associates: tcpdump -n -i iwm0 -y IEEE802_11_RADIO -s 4096 -w /tmp/iwm.pcap You can send the resulting /tmp/iwm.pcap file directly to me. Thanks!
Re: iwm: Intel Wireless AC 3160 fails to connect to access point
On Wed, 27 May 2020 10:21:29 +0200 Stefan Sperling wrote: > On Wed, May 27, 2020 at 01:02:18AM -0700, Brandon Sahlin wrote: > > > > iwm0: received msg 1/4 of the 4-way handshake from > > > > 38:3b:c8:21:5d:fa > > > > iwm0: sending msg 2/4 of the 4-way handshake to > > > > 38:3b:c8:21:5d:fa > > > > > > If the handshake fails like this, that usually means the key is wrong. > > > Are you sure the WPA key is configured correctly? > > > > > > Does it work on an unecrypted AP? > > > > > > Does it work on a different WPA AP? > > > > > > > The key is correct. I literally copied the /etc/hostname.iwm0 file from > > the working 6.6 installation and have rechecked it multiple times since. > > Please try to configure the interface manually with ifconfig, rather > than relying on /etc/netstart to do it for you. > > > If I disable encryption on the access point, it connects. The crazy > > thing is the iwm interface will connect to an iphone acting as an > > encrypted hotspot, but not this access point which it worked fine with > > for years. > > Still looks like a bad key to me. > > > The failure to connect only occured after I installed 6.7 > > over the working 6.6 installation, so my guess is that the code changes > > between releases are responsible for the problem. > > Yes. We need to determine where that code change might have occurred. > > What I am assuming for now is that you are using some crazy characters in > your wpa passphrase and that netstart or something else is not processing > them correctly, resulting in a wrong key being installed in the kernel. > > But that's just a guess. I don't have facts other than that msg 2/4 is > failing. This symptom very strongly points towards a wrong WPA key. > There is no other reasonable explanation I could think of. > > If you could tell us whether manual configuration with ifconfig works or not, > that would help a lot to decide where to look next. > After some trial and error, I found the problem. My rather crufty /etc/hostname.iwm0 file set the mode to 11n. This worked with OpenBSD 6.6 with the problematic access point, but not with OpenBSD 6.7. Commenting out the mode line let the interface card conect in 11g mode. The odd thing is that having the mode set to 11n worked with one access point (iphone 8), giving a reported 11n connection in ifconfig, but fails to complete the handshake with the problematic access point.
Re: KARL relinking deletes second kernel install set
It's important to note that the SHA256 hash checked against /bsd stored in /var/db each time reorder_kernel is called has no bearing on the integrity or consistency of the files present at compile-time for the next reordering in /usr/share/relink. If a signed SHA256.sig file (or two, GENERIC.sig and GENERIC.MP.sig) for all the individual link-kit objects from the 53mb kernel.tgz file embedded in base67.tgz were also present inside base67.tgz in the relink dir next to kernel.tgz, all the signatures could be verified before relinking for either GENERIC or GENERIC.MP and the objects reordered each time from either relink location would be guaranteed to be the same ones from the initial release. Then repopulating them if they are deleted in either or both locations wouldn't require reordering two kernels or maintaining two sets of uncompressed objects, if need be kernel.tgz could be extracted again for either configuration and the signatures verified before running make once on one set of objects. On Thu, May 28, 2020, 03:57 Stuart Henderson wrote: > On 2020/05/27 22:50, Connor Schech wrote: > > I compressed the GENERIC link kit with tar czf and it becomes 114MB, all > > other things being equal to what is done now. That becomes significant > for > > users with many instances or embedded devices. There are trade-offs > > involved, so to speak. > > Relinking once is already quite heavy and makes some systems unusable, > this at least applies to slower machines using the architectures with > wide hardware support in the kernel, i386 probably being the worst case > - some of the smaller arches like landisk cope better, partly because > there's less in the kernel and partly because they use ld.bfd which > uses less RAM. Extracting from tar.gz and linking twice is going to > be way too much for these. > >
Re: KARL relinking deletes second kernel install set
On 2020/05/27 22:50, Connor Schech wrote: > I compressed the GENERIC link kit with tar czf and it becomes 114MB, all > other things being equal to what is done now. That becomes significant for > users with many instances or embedded devices. There are trade-offs > involved, so to speak. Relinking once is already quite heavy and makes some systems unusable, this at least applies to slower machines using the architectures with wide hardware support in the kernel, i386 probably being the worst case - some of the smaller arches like landisk cope better, partly because there's less in the kernel and partly because they use ld.bfd which uses less RAM. Extracting from tar.gz and linking twice is going to be way too much for these.
