Re: ERR=20:"unable to get local issuer certificate"

[David Newman]

On 11/18/20 8:11 PM, Theo Buehler wrote:
> On Wed, Nov 18, 2020 at 03:16:57PM -0800, David Newman wrote:
>> Do recent complaints about certificate chains [1] [2] also apply when a
>> client running OpenBSD 6.8 uses a self-signed cert, and there are no
>> intermediate certs?
> 
> This is unrelated. The complaints you mention are due to a deliberate
> difference between the old TLS stack and the new TLSv1.3 stack that was
> enabled server side in OpenBSD 6.8. We hoped that we could get away
> without auto chain but as it turns out some important enough software
> depends on it...
> 
>> Since upgrading to OpenBSD 6.8, a machine running the bacula-client
>> backup package has been throwing "unable to get local issuer
>> certificate" warnings. With the same certs and configuration on OpenBSD
>> 6.7, backups ran to completion without errors warnings.
> 
> OpenBSD 6.8 not only enabled the TLSv1.3 server in libssl, but it also
> includes a new X.509 verifier in libcrypto [1]. This verifier has a
> completely new design to fix major issues with the old one. There are
> some bugs, and in some corner cases we don't match the behavior of the
> old one.  Much of this API is undocumented, and we fail to replicate
> behavior parts the ecosystem relies on.
> 
> The issue you are seeing is known [2] and should be fixed in -current.
> The most important pieces of the puzzle are in [3] and [4].  We will see
> about how best to deal with this and with other problems in 6.8 fairly
> soon.
> 
> I don't think you can eliminate this warning without changing either
> libcrypto or your setup.

Thanks, Theo. Your explanation is very clear and I now understand the
source of the warning.

dn


> 
> [1]: https://undeadly.org/cgi?action=article;sid=20200921105847
> [2]: https://github.com/znc/znc/issues/1763
> [3]: https://marc.info/?l=openbsd-cvs&m=160546290826930&w=2
> [4]: https://marc.info/?l=openbsd-cvs&m=160512059417991&w=2
> 

Re: ERR=20:"unable to get local issuer certificate"

[Theo Buehler]

On Wed, Nov 18, 2020 at 03:16:57PM -0800, David Newman wrote:
> Do recent complaints about certificate chains [1] [2] also apply when a
> client running OpenBSD 6.8 uses a self-signed cert, and there are no
> intermediate certs?

This is unrelated. The complaints you mention are due to a deliberate
difference between the old TLS stack and the new TLSv1.3 stack that was
enabled server side in OpenBSD 6.8. We hoped that we could get away
without auto chain but as it turns out some important enough software
depends on it...

> Since upgrading to OpenBSD 6.8, a machine running the bacula-client
> backup package has been throwing "unable to get local issuer
> certificate" warnings. With the same certs and configuration on OpenBSD
> 6.7, backups ran to completion without errors warnings.

OpenBSD 6.8 not only enabled the TLSv1.3 server in libssl, but it also
includes a new X.509 verifier in libcrypto [1]. This verifier has a
completely new design to fix major issues with the old one. There are
some bugs, and in some corner cases we don't match the behavior of the
old one.  Much of this API is undocumented, and we fail to replicate
behavior parts the ecosystem relies on.

The issue you are seeing is known [2] and should be fixed in -current.
The most important pieces of the puzzle are in [3] and [4].  We will see
about how best to deal with this and with other problems in 6.8 fairly
soon.

I don't think you can eliminate this warning without changing either
libcrypto or your setup.

[1]: https://undeadly.org/cgi?action=article;sid=20200921105847
[2]: https://github.com/znc/znc/issues/1763
[3]: https://marc.info/?l=openbsd-cvs&m=160546290826930&w=2
[4]: https://marc.info/?l=openbsd-cvs&m=160512059417991&w=2

ERR=20:"unable to get local issuer certificate"

[David Newman]

Do recent complaints about certificate chains [1] [2] also apply when a
client running OpenBSD 6.8 uses a self-signed cert, and there are no
intermediate certs?

Since upgrading to OpenBSD 6.8, a machine running the bacula-client
backup package has been throwing "unable to get local issuer
certificate" warnings. With the same certs and configuration on OpenBSD
6.7, backups ran to completion without errors warnings.

I asked previously on bacula-users [3], and was told this is something
with LibreSSL 3.2.2. The two citations below are about cert chains, but
the only certs here are a single self-signed root cert and a single
client cert issued by that CA.

Does something in the certs and/or the config need to change for this to
run clean?

dn

[1] https://marc.info/?l=openbsd-misc&m=160550705202129&w=2

[2] https://marc.info/?l=libressl&m=160457839621584&w=2


[3]

> Director: FreeBSD 12.2, bacula-server-9.6.6 from pkgs
> Client: OpenBSD 6.8, bacula-client-9.6.5 from pkgs
> 
> After upgrading a bacula client's OS from OpenBSD 6.7 to 6.8, nightly
> backups run successfully but throw this warning:
> 
> ERR=20:"unable to get local issuer certificate"
> 
> This setup uses self-signed certificates and worked without errors or
> warnings before this OS upgrade.
> 
> There has been no bacula configuration change on either the client or
> director . A diff of the client bacula-fd.conf file (excerpted below)
> before and after the upgrade shows no change.
> 
> I tried revoking the old client cert and generating a new one, but this
> had no effect on the warning message.
> 
> I also tried command-line "openssl s_client -connect" commands both
> ways. Both connections worked on the respective ports 9101 and 9102.
> 
> Besides the bacula client configuration -- which hasn't changed, aside
> from pointing to new certs with the same filenames -- is there something
> else that needs tweaking on the client?

-

> client bacula-fd.conf
> 
> Director {
>   Name = nye-dir
>  ..
> 
>   TLS Require = yes
>   TLS Enable = yes
>   TLS Verify Peer = yes
> 
>  # Allow only the Director to connect
>   TLS Allowed CN = "backups.example.com"
>   TLS CA Certificate File = /etc/bacula/cacert.pem
>   TLS Certificate = /etc/bacula/client.pem
>   TLS Key = /etc/bacula/client.key
> 
> }
> 
> ..
> 
> FileDaemon {
>   Name = client-fd
>   FDport = 9102  # where we listen for the director
>   WorkingDirectory = /var/db/bacula
>   Pid Directory = /var/run
>   Maximum Concurrent Jobs = 20
> 
>   TLS Require = yes
>   TLS Enable = yes
> 
>   TLS CA Certificate File = /etc/bacula/cacert.pem
>   TLS Certificate = /etc/bacula/client.pem
>   TLS Key = /etc/bacula/client.key
> 
> }

Re: seafile client doesn't sync files

[Stuart Henderson]

On 2020-11-18, avv. Nicola Dell'Uomo  
wrote:
> Hi Stuart,
>
> Il 17/11/20 12:45, Stuart Henderson ha scritto:
>> On 2020/11/14 21:02, avv. Nicola Dell'Uomo wrote:
>>> Hi Stuart,
>>>
>>> thank you for your help!
>>>
>>> Now it works (almost).
>>>
>>> The matter here was that login.conf limits were not high enough.
>>>
>>> With my server configuration seafile client opens ~ 43.000 files: I really 
>>> didn't expect such
>>> an high limit, so I set it to 8192 in login.conf.
>>>
>>> Now it works, but it definitely wastes an exaggerate amount of resources.
>>>
>>> When I close seafile client, kern.nfiles count drop form ~ 44.000 to ~ 890!
>> If you have that many files in the monitored directory tree, it's expected.
>
> hope this helps: I do have this many files in the directory tree;  \
> however, when I manually sync each library (autosync off), files \
> count never raises and everything definitely syncs in a few seconds (for \
> huge libraries).
> However the situation changes drastically when I enable autosync.

I guess "autosync" is what is telling it to use libinotify / kqueue.

> Moreover the client behaves differently in linux and in MacOS (it does not
> open all these files even with autosync enabled).

yes, I have explained about this.

Re: [SPAM] Re: APU4 hardware network interfaces tied together

[Chris Cappuccio]

Stuart Henderson [s...@spacehopper.org] wrote:
> 
> Do you have evidence to back this up? People were saying the same about
> PCEngines not being reliable compared to Soekris too. It all seems nonsense.
> Old rpi 1 and 2 machines are still running fine doing the job they were
> intended to do. I'm not claiming there's anything amazing about them but
> if they're capable of doing the job in the first place I don't see any
> real concern about hardware reliability.
> 

After some 100 APU units, both the realtek and intel based ethernet chip
versions, the only failure I've had is when one of the RTC batteries blew
up all over the board. And I've used the GPIO extensively. The boards are
very reliable in my experience. The Soekris reputation went south when
they used a buggy intel chip, which is really a problem with Intel and
not Soekris, but unfortunately that probably helped to end Soekris.

Re: seafile client doesn't sync files

[avv. Nicola Dell'Uomo]

Hi Stuart,

Il 17/11/20 12:45, Stuart Henderson ha scritto:

On 2020/11/14 21:02, avv. Nicola Dell'Uomo wrote:

Hi Stuart,

thank you for your help!

Now it works (almost).

The matter here was that login.conf limits were not high enough.

With my server configuration seafile client opens ~ 43.000 files: I really 
didn't expect such
an high limit, so I set it to 8192 in login.conf.

Now it works, but it definitely wastes an exaggerate amount of resources.

When I close seafile client, kern.nfiles count drop form ~ 44.000 to ~ 890!

If you have that many files in the monitored directory tree, it's expected.


hope this helps: I do have this many files in the directory tree;  \

however, when I manually sync each library (autosync off), files \

count never raises and everything definitely syncs in a few seconds (for \

huge libraries).

However the situation changes drastically when I enable autosync.

Moreover the client behaves differently in linux and in MacOS (it does not

open all these files even with autosync enabled).

Obviously I'm referring to syncing exactly the the same libraries...

That's what led me to think this could be due to a bug.


Moreover seafile client consume a huge amount of cpu time.

If you have the ports tree installed you can try updating libinotify
- change 20170711 to 20180201 in /usr/ports/devel/libinotify, "make
makesum" and "make update", there are some changes in this that should
reduce memory use and I think maybe also reduce cpu load. If there are
problems or it doesn't help then revert to the version in packages
("pkg_add -r -D downgrade libinotify")


I'll give it a try: I can use the client with no major problem at the 
moment \


, but autosyncing would be welcomed (and I think also future users will \

appreciate it ...).

Thank you again for your help!!!

Nicola

[RESOLVED] Re: Wrong net in vlan

[Axel Rau]

Hi Stuart,

> Am 18.11.2020 um 13:20 schrieb Stuart Henderson :
> 
> On 2020/11/18 12:48, Axel Rau wrote:
>> From /etc/dhcpd.conf:
>> - - -
>> shared-network WLAN-NET {
> 
> This is your problem.

Oh yes. The art of carefully reading . . .

Thanks a lot,
Axel
---
PGP-Key: CDE74120  ☀  computing @ chaos claudius



signature.asc
Description: Message signed with OpenPGP

Re: Wrong net in vlan

[Stuart Henderson]

On 2020/11/18 12:48, Axel Rau wrote:
> From /etc/dhcpd.conf:
> - - -
> shared-network WLAN-NET {

This is your problem.

Re: Wrong net in vlan

[Axel Rau]

> Am 18.11.2020 um 11:00 schrieb Stuart Henderson :
> 
> On 2020-11-18, Axel Rau  wrote:
>> I think, the problem is that all vlans share the same lladr (see recent 
>> ifconfigs).
>> To allow dhcpd to distinguish the vlans, I have to set the mac addresses 
>> manually.
>> Will try this later.
> 
> No this is totally normal, there is no need to touch the MAC address.
> All you need to do is configure the parent interface "up", set the
> tag and parent interface, add the subnet to dhcpd.conf (and add the
> interface to dhcpd_flags if you don't let it pick them automatically).

AFAIK, that was exactly, what I did:

dhcpd_flags="em0 em3 vlan11 vlan12 vlan13 vlan14 vlan15 vlan16"

gw1# ifconfig vlan
vlan11: flags=8843 mtu 1500
lladdr 00:60:e0:5a:75:43
index 13 priority 0 llprio 3
encap: vnetid 11 parent em3 txprio packet rxprio outer
groups: vlan
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 172.16.11.1 netmask 0xff00 broadcast 172.16.11.255
inet6 fe80::260:e0ff:fe5a:7543%vlan11 prefixlen 64 scopeid 0xd
inet6 :::16:11::a prefixlen 80
vlan12: flags=8843 mtu 1500
lladdr 00:60:e0:5a:75:43
index 14 priority 0 llprio 3
encap: vnetid 12 parent em3 txprio packet rxprio outer
groups: vlan
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 172.16.12.1 netmask 0xff00 broadcast 172.16.12.255
inet6 fe80::260:e0ff:fe5a:7543%vlan12 prefixlen 64 scopeid 0xe
inet6 :::16:12::a prefixlen 80
vlan13: flags=8843 mtu 1500
lladdr 00:60:e0:5a:75:43
index 15 priority 0 llprio 3
encap: vnetid 13 parent em3 txprio packet rxprio outer
groups: vlan
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 172.16.13.1 netmask 0xff00 broadcast 172.16.13.255
inet6 fe80::260:e0ff:fe5a:7543%vlan13 prefixlen 64 scopeid 0xf
inet6 :::16:13::a prefixlen 80
vlan14: flags=8843 mtu 1500
lladdr 00:60:e0:5a:75:43
index 16 priority 0 llprio 3
encap: vnetid 14 parent em3 txprio packet rxprio outer
groups: vlan
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 172.16.14.1 netmask 0xff00 broadcast 172.16.14.255
inet6 fe80::260:e0ff:fe5a:7543%vlan14 prefixlen 64 scopeid 0x10
inet6 :::16:14::a prefixlen 80
vlan15: flags=8843 mtu 1500
lladdr 00:60:e0:5a:75:43
index 17 priority 0 llprio 3
encap: vnetid 15 parent em3 txprio packet rxprio outer
groups: vlan
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 172.16.15.1 netmask 0xff00 broadcast 172.16.15.255
inet6 fe80::260:e0ff:fe5a:7543%vlan15 prefixlen 64 scopeid 0x11
inet6 :::16:15::a prefixlen 80
vlan16: flags=8843 mtu 1500
lladdr 00:60:e0:5a:75:43
index 18 priority 0 llprio 3
encap: vnetid 16 parent em3 txprio packet rxprio outer
groups: vlan
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 172.16.16.1 netmask 0xff00 broadcast 172.16.16.255
inet6 fe80::260:e0ff:fe5a:7543%vlan16 prefixlen 64 scopeid 0x12
inet6 :::16:16::a prefixlen 80
gw1# ifconfig em3
em3: flags=8b43 mtu 
1500
lladdr 00:60:e0:5a:75:43
index 4 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 172.16.63.1 netmask 0xff00 broadcast 172.16.63.255
inet6 fe80::260:e0ff:fe5a:7543%em3 prefixlen 64 scopeid 0x4
inet6 :::16::a prefixlen 80
gw1# ifconfig carp3
carp3: flags=8843 mtu 1500
lladdr 00:00:5e:00:01:04
index 12 priority 15 llprio 3
carp: MASTER carpdev em3 vhid 4 advbase 1 advskew 0
groups: carp
status: master
inet 172.16.63.9 netmask 0xff00 broadcast 172.16.63.255
inet6 fe80::200:5eff:fe00:104%carp3 prefixlen 64 scopeid 0xc
inet6 :::16::c prefixlen 80

>From /etc/dhcpd.conf:
- - -
shared-network WLAN-NET {
option  domain-name "wlan.chaos1.de";
option  domain-name-servers 192.1.2.3, 80.12.4.171;
option  ntp-servers 192.1.2.4, 80.12.4.170;

subnet  172.16.63.0 netmask 255.255.255.0 {
option routers 172.16.63.1;
option  ntp-servers 192.1.2.4, 80.12.4.170;

range 172.16.63.200 172.16.63.230;

#   cap01 MikroTik WLAN Access Point
host static-client {
hardware ethernet 4a:0b:bc:54:0c:fa;
fixed-address 172.16.63.11;
}
#   cap02 MikroTik WLAN Access Point
host static-client {
hardware ethernet c4:ad:34:f5:4d:

Re: limit UDP connection rate with PF pass rule

[mabi]

‐‐‐ Original Message ‐‐‐
On Tuesday, November 17, 2020 11:50 PM, Stuart Henderson  
wrote:

> These packets are most likely sent from spoofed source addresses.
>
> Assuming this is the case, the address you are seeing on the packets
> would not be the attacker but the victim.

That totally makes sense because why would google be sending me all these DNS 
packets from different IP addresses from their network.

Here is an example of packet which was logged by Bro (now called Zeek) on my 
NSM and there are tons of these during a time window of 3 minutes:

{"ts":"2020-11-17T14:02:00.059396Z","uid":"CD5YJQ2eVZKX6bhyoj","id.orig_h":"74.125.18.1","id.orig_p":51423,"id.resp_h":"","id.resp_p":53,"proto":"udp","trans_id":39451,"rcode":3,"rcode_name":"NXDOMAIN","AA":false,"TC":false,"RD":false,"RA":false,"Z":0,"rejected":false}

> PF doesn't support this type of request rate limiting on UDP
> connections. It's a bit dangerous to do so because in many cases it's
> trivial to spoof UDP packets and blocking packets from a source on the
> basis of this can result in you DoS'ing yourself. This isn't such a
> problem with TCP because only someone on the network path between
> you and the supposed source address (i.e. someone with access to
> the ACK packets) is likely to be able to successfully spoof packets.

I understand and that's what I thought. So there is no much point in me trying 
to add "max-src-states 10" for example to my pass in rule for DNS UDP traffic 
to my DNS servers.


> To mitigate this you might like to read the manual for your
> authoritative nameserver software about RRL (response rate limiting),
> many support it directly (including BIND and NSD), if not then you could
> front-end with something that can handle it itself like dnsdist.
>
> The DNS RRL techniques typically still reply to a proportion of queries
> (either directly with the answer, or with a "retry over TCP" response
> code) reducing impact if the source IP is also used by real queries as
> well as the attack traffic.

I've been looking into that in the past and as I am using PowerDNS 4.0.3 the 
only valid config parameters I could find and which I already have in place are 
the following:

overload-queue-length=1
max-tcp-connections=5

There is as far as I know no such parameter as "max-udp-connections".

Re: Wrong net in vlan

[Stuart Henderson]

On 2020-11-18, Axel Rau  wrote:
> I think, the problem is that all vlans share the same lladr (see recent 
> ifconfigs).
> To allow dhcpd to distinguish the vlans, I have to set the mac addresses 
> manually.
> Will try this later.

No this is totally normal, there is no need to touch the MAC address.
All you need to do is configure the parent interface "up", set the
tag and parent interface, add the subnet to dhcpd.conf (and add the
interface to dhcpd_flags if you don't let it pick them automatically).

Re: Wrong net in vlan

[Axel Rau]

I think, the problem is that all vlans share the same lladr (see recent 
ifconfigs).
To allow dhcpd to distinguish the vlans, I have to set the mac addresses 
manually.
Will try this later.

Axel
---
axel@chaos1.de  PGP-Key:29E99DD6   computing @ chaos claudius


> Am 18.11.2020 um 00:09 schrieb Stuart Henderson :
> 
> On 2020-11-17, Axel Rau  wrote:
>> 
>> 
>> --Apple-Mail=_AD48A584-E586-4B64-9277-CAE8E8103BC1
>> Content-Type: text/plain;
>>charset=utf-8
>> Content-Transfer-Encoding: 8bit
>> 
>> Hi all.
>> 
 Am 16.11.2020 um 11:09 schrieb Axel Rau :
>>> 
>>> - - -
>>> From /etc/rc.conf.local:
>>> - - -
>>> dhcpd_flags="em0 em3 vlan11 vlan12 vlan13 vlan14 vlan15 vlan16"
>>> - - -
>> 
>> I have still no resolution. dhcpd preovides always an address from the 
>> subnet 172.16.11/24 regardless from which vlan comes the request.
>> 172.16.11/24 is the subnet associated with the 1st vlan on em3 (vlan11)
> 
> Your emails are a bit confusing. You have sent one email showing
> current config from ifconfig for vlan11 and vlan13, another email
> showing hostname.if files for vlan11 and vlan12, an excerpt from
> your dhcpd.conf file showing configs for the subnets you showed
> on vlan11 and vlan12, and log from an example request on vlan13.
> 
> Check your configuration methodically, make sure you have sections
> in dhcpd.conf for all the networks you have told it to listen to
> that match the networks configured in hostname.if files.
> 
> Is dhcpd.conf just missing a subnet section for 172.16.13.0?
> 
> If things may have got confused during testing, restart the system to
> make sure the interfaces are configured as set in the files.
> 
>> - - -
>> hardware-type must be the name of a hardware interface type. Currently, the 
>> ethernet, token-ring and fddi physical interface types are recognized, 
>> although support for DHCP-over-IPsec virtual interface type ipsec-tunnel is 
>> provided. The hardware-address should be a set of colon-separated 
>> hexadecimal octets (0-ff) or a hostname that can be looked up in ethers(5) 
>>  when the configuration is read.
>> - - -
> 
> You are unlikely to need to set this. In any event a vlan is an
> ethernet interface type.
> 
>> Are vlans aresupported by dhcpd at all?
> 
> It doesn't need any special support, they just appear as a normal
> ethernet-like interface.
> 
>> 
>> Axel
>> ---
>> PGP-Key: CDE74120  ☀  computing @ chaos claudius
>> 
>> 
>> --Apple-Mail=_AD48A584-E586-4B64-9277-CAE8E8103BC1
>> Content-Transfer-Encoding: 7bit
>> Content-Disposition: attachment;
>>filename=signature.asc
>> Content-Type: application/pgp-signature;
>>name=signature.asc
>> Content-Description: Message signed with OpenPGP
>> 
>> 
>> --Apple-Mail=_AD48A584-E586-4B64-9277-CAE8E8103BC1--
>> 
>> 
>