Re: Possible typo in fw_update
Andrew Hewus Fresh writes:
> On Sun, Dec 11, 2022 at 08:06:24PM -0500, Rob Whitlock wrote:
> > On line 408, fw_update has the expression ${LOCALSRC:#file:}. The parameter
> > substitution ${name:#word} is not documented in the manual page for ksh yet
> > its behavior seems to be equivalent to ${LOCALSRC#file:}. Assuming this is
> > a typo, a patch is provided to remove the colon. If it is not a typo, could
> > someone explain what this syntax does?
>
> It was a typo, committed, thanks!
>
>
> > Is this was a typo however, and this parameter substitution is not
> > officially supported, why did ksh not complain?
>
> Not having read it, I assume the implementation reads the : and sets a
> flag that says "must be be NULL" for the -, +, =, and ? substitutions
> and the validation that the next character is one of those four is
> missing.
It does this:
/* allow :# and :% (ksh88 compat) */
if (c == ':') {
*wp++ = CHAR, *wp++ = c;
c = getsc();
}
... introduced in lex.c 1.11 in 1998. I think it's safe.
> An email to bugs@ with this question might get the attention of folks
> who are more familiar with ksh internals and whether fixing this being
> too accepting is worth the code and the likelihood of breaking scripts
> with typos like this one.
>From prior excavation deep in the bowels of yylex:
${-expansion expects a variable name and modifiers. The
name is scanned for by get_brace_var below and then
modification by ``#'' or ``%'' is detected. ``:#'' and
``:%'' are also accepted for compatibility with ksh88.
This seems like a good opportunity for shameless self-promotion of
the full excavation at http://zeus.jtan.com/~chohag/ksh/ (section
347 "Detect ${-expansion", page 147).
Matthew
Re: dhcpinform only on dhcpd -u
Hi,
Perhaps I was not really clear about this.
What is the rationale to only have DHCP server
to reply to DHCPINFORM messages and never serve any ip leases
while we bind it to UDP socket?
Currently, dhcp server will only serve ip addresses if its using raw sockets,
replaying to broadcasts etc.
On Wednesday, October 26, 2022 at 08:43:16 p.m. GMT+9, All
wrote:
Hi,
in dhcpd.c we have:
if (is_udpsock && packet->packet_type != DHCPINFORM) {
log_info("Unable to handle a DHCP message type=%d on UDP "
"socket", packet->packet_type);
return;
}
Why do we not want to process normal dhcp messages like discover/request?
If you want dhcpd to not bother with raw packets and broadcasts and just focus
on unicasts this would be a logical option.
Re: Possible typo in fw_update
On Sun, Dec 11, 2022 at 08:06:24PM -0500, Rob Whitlock wrote:
> On line 408, fw_update has the expression ${LOCALSRC:#file:}. The parameter
> substitution ${name:#word} is not documented in the manual page for ksh yet
> its behavior seems to be equivalent to ${LOCALSRC#file:}. Assuming this is
> a typo, a patch is provided to remove the colon. If it is not a typo, could
> someone explain what this syntax does?
>
> Is this was a typo however, and this parameter substitution is not
> officially supported, why did ksh not complain?
I would guess syntax ${name:#word} is akin to other colon substitutions
${name:-word}, ${name:=word}, ${name:+word}, ${name:?word} although
it is not documented.
${name:%word} works too (and is not documented either)
And actually man page says that colon can be omitted from :- := :+ :?
which hints that # and % are treated as substitutions with omitted colon.
I wonder if we would rather update man page of ksh.
-Kastus
Re: Possible typo in fw_update
On Sun, Dec 11, 2022 at 08:06:24PM -0500, Rob Whitlock wrote:
> On line 408, fw_update has the expression ${LOCALSRC:#file:}. The parameter
> substitution ${name:#word} is not documented in the manual page for ksh yet
> its behavior seems to be equivalent to ${LOCALSRC#file:}. Assuming this is
> a typo, a patch is provided to remove the colon. If it is not a typo, could
> someone explain what this syntax does?
It was a typo, committed, thanks!
> Is this was a typo however, and this parameter substitution is not
> officially supported, why did ksh not complain?
Not having read it, I assume the implementation reads the : and sets a
flag that says "must be be NULL" for the -, +, =, and ? substitutions
and the validation that the next character is one of those four is
missing.
An email to bugs@ with this question might get the attention of folks
who are more familiar with ksh internals and whether fixing this being
too accepting is worth the code and the likelihood of breaking scripts
with typos like this one.
> Rob
>
> diff --git usr.sbin/fw_update/fw_update.sh usr.sbin/fw_update/fw_update.sh
> index 4b77d4c7bd7..dbc80257228 100644
> --- usr.sbin/fw_update/fw_update.sh
> +++ usr.sbin/fw_update/fw_update.sh
> @@ -405,7 +405,7 @@ if [ "$LOCALSRC" ]; then
> FWURL="${LOCALSRC}"
> LOCALSRC=
> else
> - LOCALSRC="${LOCALSRC:#file:}"
> + LOCALSRC="${LOCALSRC#file:}"
> ! [ -d "$LOCALSRC" ] &&
> echo "The path must be a URL or an existing directory"
> >&2 &&
> exit 1
No
I have a Protectli box that is the router for my home network. The home network uses U-Verse to connect to the outside, and has separate Ethernet networks for servers, wired clients, and Wi-Fi IoT clients. U-Verse supplies their own box (a "Residential Gateway" or RG) that sits at the connection points. The RG throws a tantrum if it detects an internal router or multi-homed devices, so the OpenBSD box is set up as a transparent filtering bridge so the RG thinks all the devices are connected directly to it. The OpenBSD box has Ethernet ports for the U-Verse RG and one for the three internal networks, with pf filtering the packets. The /etc/hostname.if files provide an IP address for the interface for the server network and one for the Wi-Fi interface (these are on different networks). The /etc/hostname.if files for the U-Verse and wired client Ethernet ports have just a description. The Protectli was running (I think) OpenBSD 6.2, but suffered a disk failure and I couldn't find my backup, so I installed a fresh OpenBSD 7.2 on it and added the users and config files (I had current versions of those). The config files are pretty minimal: /etc/hostname.if files for the four Ethernet ports and the bridge, /etc/sysctl.conf to set net.inet.ip.forwarding=1, pf.conf for the rules. There aren't any other services running on the box (other boxes are used for DHCP, DNS, etc.). Initially, the server and Wi-Fi Ethernet ports had traffic and packets were routed between them, but there was no traffic on the wired clients nor U-Verse Ethernet ports, and no packets got between them. A client on Wi-Fi could ping a server and vice versa, and other servers could reach the OpenBSD box. But clients couldn't reach servers, and nothing could get outside. All interfaces looked right when viewed using ifconfig, and the bridge looked right (it was up and had the four interfaces). There were no errors during startup, nor when running netstart. Changing the /etc/hostname.if files for the U-Verse and client ports to add an 'inet' line with a dummy IP address made it all start working. Before, they just had a line with "description" and text. Questions: (1) I'd like to understand the interfaces worked without having IP addresses in OpenBSD 6 but not in OpenBSD 7. They showed as up and as part of the bridge, but no traffic. (2) Also, I have several old machines that can no longer SSH into the OpenBSD 7 box. They get an error "no hostkey alg". Is there an easy way to get the OpenBSD box to accept connections from older clients? Presumably I need to enable older key algorithms, but after hunting through the OpenSSH manual I can't see what I need to do. The packet rules block access to the OpenBSD box from outside. Thank you for any help, --Randall
Need to add dummy IP addresses to interfaces in OpenBSD 7
[[[ My apologies, I accidentally sent this before I'd finished it. ]]] I have a Protectli box that is the router for my home network. The home network uses U-Verse to connect to the outside, and has separate Ethernet networks for servers, wired clients, and Wi-Fi IoT clients. U-Verse supplies their own box (a "Residential Gateway" or RG) that sits at the connection points. The RG throws a tantrum if it detects an internal router or multi-homed devices, so the OpenBSD box is set up as a transparent filtering bridge so the RG thinks all the devices are connected directly to it. The OpenBSD box has Ethernet ports for the U-Verse RG and one for the three internal networks, with pf filtering the packets. The /etc/hostname.if files provide an IP address for the interface for the server network and one for the Wi-Fi interface (these are on different networks). The /etc/hostname.if files for the U-Verse and wired client Ethernet ports have just a description. The Protectli was running (I think) OpenBSD 6.2, but suffered a disk failure and I couldn't find my backup, so I installed a fresh OpenBSD 7.2 on it and added the users and config files (I had current versions of those). The config files are pretty minimal: /etc/hostname.if files for the four Ethernet ports and the bridge, /etc/sysctl.conf to set net.inet.ip.forwarding=1, pf.conf for the rules. There aren't any other services running on the box (other boxes are used for DHCP, DNS, etc.). Initially, the server and Wi-Fi Ethernet ports had traffic and packets were routed between them, but there was no traffic on the wired clients nor U-Verse Ethernet ports, and no packets got between them. A client on Wi-Fi could ping a server and vice versa, and other servers could reach the OpenBSD box. But clients couldn't reach servers, and nothing could get outside. All interfaces looked right when viewed using ifconfig, and the bridge looked right (it was up and had the four interfaces). There were no errors during startup, nor when running netstart. Changing the /etc/hostname.if files for the U-Verse and client ports to add an 'inet' line with a dummy IP address made it all start working. Before, they just had a line with "description" and text. Questions: (1) I'd like to understand the interfaces worked without having IP addresses in OpenBSD 6 but not in OpenBSD 7. They showed as up and as part of the bridge, but no traffic. (2) Also, I have several old machines that can no longer SSH into the OpenBSD 7 box. They get an error "no hostkey alg". Is there an easy way to get the OpenBSD box to accept connections from older clients? Presumably I need to enable older key algorithms, but after hunting through the OpenSSH manual I can't see what I need to do. The packet rules block access to the OpenBSD box from outside. Thank you for any help, --Randall
Possible typo in fw_update
On line 408, fw_update has the expression ${LOCALSRC:#file:}. The parameter
substitution ${name:#word} is not documented in the manual page for ksh yet
its behavior seems to be equivalent to ${LOCALSRC#file:}. Assuming this is
a typo, a patch is provided to remove the colon. If it is not a typo, could
someone explain what this syntax does?
Is this was a typo however, and this parameter substitution is not
officially supported, why did ksh not complain?
Rob
diff --git usr.sbin/fw_update/fw_update.sh usr.sbin/fw_update/fw_update.sh
index 4b77d4c7bd7..dbc80257228 100644
--- usr.sbin/fw_update/fw_update.sh
+++ usr.sbin/fw_update/fw_update.sh
@@ -405,7 +405,7 @@ if [ "$LOCALSRC" ]; then
FWURL="${LOCALSRC}"
LOCALSRC=
else
- LOCALSRC="${LOCALSRC:#file:}"
+ LOCALSRC="${LOCALSRC#file:}"
! [ -d "$LOCALSRC" ] &&
echo "The path must be a URL or an existing directory"
>&2 &&
exit 1
ex/vi 100% CPU when STDIN_FILENO set to O_NONBLOCK
...
42136 ex RET read -1 errno 35 Resource temporarily unavailable
42136 ex CALL read(0,0x3d94b585400,0xff)
42136 ex RET read -1 errno 35 Resource temporarily unavailable
42136 ex CALL read(0,0x3d94b585400,0xff)
...
this condition can be reproduced with:
#include
#include
#include
#include
#include
#define TARGET_FD STDIN_FILENO
int main(int argc, char *argv[]) {
int flags, status;
pid_t pid;
pid = fork();
if (pid < 0) err(1, "fork failed");
if (pid == 0) {
flags = fcntl(TARGET_FD, F_GETFL, 0);
if (flags == -1) err(1, "fcntl getfl failed");
flags |= O_NONBLOCK;
flags = fcntl(TARGET_FD, F_SETFL, flags);
if (flags == -1) err(1, "fcntl setfl failed");
argv++;
execvp(*argv, argv);
err(1, "execvp failed");
}
wait(&status);
exit(0);
}
and then running whatever-the-above-was-compiled-to as
./whatever /usr/bin/ex
or also under modern code that for some reason sets O_NONBLOCK and
forgets to turn it off when calling out to an editor, hypothetically
https://github.com/osa1/tiny
and likely other, similar programs. Probably, O_NONBLOCK should be
disabled on STDIN_FILENO before calling out to unknown programs.
Probably, vi should be patched to not eat CPU when the previous case is
not handled.
Thoughts?
diff --git usr.bin/vi/cl/cl_main.c usr.bin/vi/cl/cl_main.c
index 33614c99594..f87a04cad8b 100644
--- usr.bin/vi/cl/cl_main.c
+++ usr.bin/vi/cl/cl_main.c
@@ -54,7 +54,7 @@ main(int argc, char *argv[])
CL_PRIVATE *clp;
GS *gp;
size_t rows, cols;
- int rval;
+ int flags, oflags, rval;
char *ttype;
/* Create and initialize the global structure. */
@@ -89,6 +89,14 @@ main(int argc, char *argv[])
/* Ex wants stdout to be buffered. */
(void)setvbuf(stdout, NULL, _IOFBF, 0);
+ /* Ensure blocking I/O to avoid 100% CPU on EAGAIN */
+ if ((flags = fcntl(STDIN_FILENO, F_GETFL, 0)) == -1)
+ exit (1);
+ oflags = flags;
+ flags &= ~O_NONBLOCK;
+ if (fcntl(STDIN_FILENO, F_SETFL, flags) == -1)
+ exit (1);
+
/* Start catching signals. */
if (sig_init(gp, NULL))
exit (1);
@@ -102,6 +110,9 @@ main(int argc, char *argv[])
/* Clean up the terminal. */
(void)cl_quit(gp);
+ /* Restore flags */
+ fcntl(STDIN_FILENO, F_SETFL, oflags);
+
/*
* XXX
* Reset the O_MESG option.
Re: Problems with IO::Socket::SSL since upgraded to 7.2
On 2022-12-11, Alceu Rodrigues de Freitas Junior wrote: > > > Em 11/12/2022 07:34, Stuart Henderson escreveu: >> On 2022-12-10, Alceu Rodrigues de Freitas Junior >> wrote: >>> If I read correctly, the Mikrotik is using an SSLv3 certificate, which I >>> guess shouldn't be in use anymore. >> >> There's no such thing as "an SSLv3 certificate", they are all just X.509 >> certs. The sslv3 refers to the type of alert, sslv3 alerts are still >> used in TLS; SSLv3 itself hasn't been supported for years. > > That's quite confusing. Since SSL v3 was deprecated, I assumed the > mentioned router was quite old and that's the reason it was failing with > newer versions of OpenBSD. TLS is a large and complicated protocol, with some new bits but also some old bits carried through from SSL, not everything xhanged. >> It doesn't necessarily use a certificate anyway, it may well be using >> ADH for this. Federico, do you have a cert configured for the api-ssl >> service on the routeros device, in "/ip service print"? > > And now I'm even more confused, looks like I'm still can't get my head > around OpenSSL. Looking at here: > > https://www.openssl.org/docs/manmaster/man1/openssl-ciphers.html#CIPHER-STRINGS > > The certificate may define the ciphers it accepts, but what does it mean > "It doesn't necessarily use a certificate anyway" and it's relation with > ADH cipher? ADH (Anonymous Diffie-Hellman key exchange) provides a comms channel that is secure to passive eavesdroppers, but doesn't provide authenticity (no proof that you're communicating with who you think you are; someone who can respond to comms, i.e. an "active" attacker, can intercept the "secure" channel). The certificates in a "normal" TLS connection are there to allow one side to prove to the other that they're the expected endpoint; in that case an active attacker wouldn't be able to intercept comms without the real endpoints noticing (as long as they're checking certificates). The guarantee you get from ADH is roughly equivalent to what you'd get if the device generated a key and self-signed certificate and the other side didn't check the cert. So actually in many cases the device would do just that. But RouterOS didn't do that, and used ADH by default instead (they could have chosen to generate a key and self-signed certificate and use "normal" TLS for this api connection, but they didn't; however if you login to the router you can configure it to do that instead). >>> Em 10/12/2022 17:01, Federico Giannici escreveu: Since I upgraded from OpenBSD 7.1 to 7.2 (amd64) I'm no longer able to use IO::Socket::SSL perl library to connect to some devices (Mikrotik routers, via their API). This is the only debug info I was able to obtain: DEBUG: .../IO/Socket/SSL.pm:842: local error: SSL connect attempt failed error:14004410:SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 alert handshake failure >> >> Maybe try connecting with openssl s_client too? That would help show if >> it's a problem specific to IO::Socket::SSL or something more general. >> Unfortunately it seems that both perl functions Net::SSLeay::set_security_level() and Net::SSLeay::CTX_set_security_level() don't work. I get the following error. Maybe they are not implemented in our version of Net::SSLeay perl library? >> >> The security level stuff was only recently added to libressl, it is still >> hidden behind #ifndef for libressl in p5-Net-SSLeay. I think you can set >> it in the ciphers string though, if it is ADH maybe you need something like >> "ADH:ALL:@SECLEVEL=0" (though in that case you would probably be better >> advised to generate and use certificates instead). > > I did some search and so I guess this relates to > https://www.openssl.org/docs/manmaster/man1/openssl-ciphers.html#CIPHER-STRINGS. > > Interesting that this can be set at IO::Socket::SSL but not (at least as > far as I could check) with Net::SSLeay, which is a dependency from the > former which let me understand that works at a lower level. There are multiple ways to set the "security level"; either at the same time as setting the cipher, or as a default for all operations. When set as part of the cipher the "cipher string" is passed through direct to the libressl (or openssl) libraries. When setting the default it uses a separate library function that Net::SSLeay does know about, but doesn't yet understand that it's available in libressl so doesn't expose it. > Finally, setting the security level to zero wouldn't increase the > chances of having issues since it allows poor options? Just checked that > in > https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_security_level.html Yes it certainly does. But considering what guarantees ADH is able to make (or more importantly _not_ make) you can see why it's disabled except at low security level. You don't want to be able to accidentally enable a cipher that also disables authentication. In
premature end of data for lang/go package (mips64)
Hello misc@ I get the following error when trying to install go (for mips64/octeon): # pkg_add go quirks-6.42 signed on 2022-10-08T21:12:07Z Ustar [http://cdn.openbsd.org/pub/OpenBSD/7.2/packages/mips64/go-1.19.1p0.tgz][go/pkg/openbsd_mips64/cmd/compile/internal/reflectdata.a]: Premature end of archive Adjusting sha for /usr/local/go/pkg/openbsd_mips64/cmd/compile/internal/reflectdata.a from /dvcLn8+FQ5qji2A6mxyIWODWY35KxCB9u4isEHanf0= to 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU= pkg_add: Installation of go-1.19.1p0 failed, partial installation recorded as partial-go-1.19.1p0 Changing /etc/installurl makes no difference. In addition to the above CDN, I have tried www.mirrorservice.org mirrors.gethosted.online mirror.laylo.io same result. How can I get around this problem? I'd like to avoid compiling on the device itself because it has limited resources for that type of thing. It is only this pkg with this problem. There are no connectivity issues. Alternatively, is it feasible to build an amd64 vm and cross-compile there, for mips64/octeon? dmesg follows: [ using 752776 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2022 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 7.2 (GENERIC.MP) #1063: Tue Sep 27 19:23:10 MDT 2022 dera...@octeon.openbsd.org:/usr/src/sys/arch/octeon/compile/GENERIC.MP real mem = 536870912 (512MB) avail mem = 521322496 (497MB) random: good seed from bootblocks mainbus0 at root: board 20002 rev 2.18, model CN3xxx/CN5xxx cpu0 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation cpu0: cache L1-I 32KB 4 way D 16KB 64 way, L2 128KB 8 way cpu1 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation cpu1: cache L1-I 32KB 4 way D 16KB 64 way, L2 128KB 8 way clock0 at mainbus0: int 5 octcrypto0 at mainbus0 iobus0 at mainbus0 simplebus0 at iobus0: "soc" octciu0 at simplebus0 octsmi0 at simplebus0 octpip0 at simplebus0 octgmx0 at octpip0 interface 0 cnmac0 at octgmx0: port 0 RGMII, address f0:9f:c2:12:31:db atphy0 at cnmac0 phy 7: AR8035 10/100/1000 PHY, rev. 2 cnmac1 at octgmx0: port 1 RGMII, address f0:9f:c2:12:31:dc atphy1 at cnmac1 phy 6: AR8035 10/100/1000 PHY, rev. 2 cnmac2 at octgmx0: port 2 RGMII, address f0:9f:c2:12:31:dd atphy2 at cnmac2 phy 5: AR8035 10/100/1000 PHY, rev. 2 com0 at simplebus0: ns16550a, 64 byte fifo com0: console dwctwo0 at iobus0 base 0x118006800 irq 56 usb0 at dwctwo0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Octeon DWC2 root hub" rev 2.00/1.00 addr 1 octrng0 at iobus0 base 0x14000 irq 0 umass0 at uhub0 port 1 configuration 1 interface 0 "SanDisk' Cruzer Fit" rev 2.00/1.00 addr 2 umass0: using SCSI over Bulk-Only scsibus0 at umass0: 2 targets, initiator 0 sd0 at scsibus0 targ 1 lun 0: removable serial.07815571020705203013 sd0: 29340MB, 512 bytes/sector, 60088320 sectors vscsi0 at root scsibus1 at vscsi0: 256 targets softraid0 at root scsibus2 at softraid0: 256 targets root on sd0a (a804a0144e807aaa.a) swap on sd0b dump on sd0b WARNING: CHECK AND RESET THE DATE! tia, --
Re: Problems with IO::Socket::SSL since upgraded to 7.2
Em 11/12/2022 07:34, Stuart Henderson escreveu: On 2022-12-10, Alceu Rodrigues de Freitas Junior wrote: If I read correctly, the Mikrotik is using an SSLv3 certificate, which I guess shouldn't be in use anymore. There's no such thing as "an SSLv3 certificate", they are all just X.509 certs. The sslv3 refers to the type of alert, sslv3 alerts are still used in TLS; SSLv3 itself hasn't been supported for years. That's quite confusing. Since SSL v3 was deprecated, I assumed the mentioned router was quite old and that's the reason it was failing with newer versions of OpenBSD. It doesn't necessarily use a certificate anyway, it may well be using ADH for this. Federico, do you have a cert configured for the api-ssl service on the routeros device, in "/ip service print"? And now I'm even more confused, looks like I'm still can't get my head around OpenSSL. Looking at here: https://www.openssl.org/docs/manmaster/man1/openssl-ciphers.html#CIPHER-STRINGS The certificate may define the ciphers it accepts, but what does it mean "It doesn't necessarily use a certificate anyway" and it's relation with ADH cipher? Em 10/12/2022 17:01, Federico Giannici escreveu: Since I upgraded from OpenBSD 7.1 to 7.2 (amd64) I'm no longer able to use IO::Socket::SSL perl library to connect to some devices (Mikrotik routers, via their API). This is the only debug info I was able to obtain: DEBUG: .../IO/Socket/SSL.pm:842: local error: SSL connect attempt failed error:14004410:SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 alert handshake failure Maybe try connecting with openssl s_client too? That would help show if it's a problem specific to IO::Socket::SSL or something more general. Unfortunately it seems that both perl functions Net::SSLeay::set_security_level() and Net::SSLeay::CTX_set_security_level() don't work. I get the following error. Maybe they are not implemented in our version of Net::SSLeay perl library? The security level stuff was only recently added to libressl, it is still hidden behind #ifndef for libressl in p5-Net-SSLeay. I think you can set it in the ciphers string though, if it is ADH maybe you need something like "ADH:ALL:@SECLEVEL=0" (though in that case you would probably be better advised to generate and use certificates instead). I did some search and so I guess this relates to https://www.openssl.org/docs/manmaster/man1/openssl-ciphers.html#CIPHER-STRINGS. Interesting that this can be set at IO::Socket::SSL but not (at least as far as I could check) with Net::SSLeay, which is a dependency from the former which let me understand that works at a lower level. Finally, setting the security level to zero wouldn't increase the chances of having issues since it allows poor options? Just checked that in https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_security_level.html My apologies if all this is too basic. Anyway good references would be appreciated. Thanks in advance, Alceu
Re: Problems with IO::Socket::SSL since upgraded to 7.2
On 12/11/22 11:34, Stuart Henderson wrote: The security level stuff was only recently added to libressl, it is still hidden behind #ifndef for libressl in p5-Net-SSLeay. I think you can set it in the ciphers string though, if it is ADH maybe you need something like "ADH:ALL:@SECLEVEL=0" (though in that case you would probably be better advised to generate and use certificates instead). I added "SSL_cipher_list => 'ADH:ALL:@SECLEVEL=0'" and it worked!!! Thank you Stuart. When you come to Sicily you have a paid beer! :-)
Re: Problems with IO::Socket::SSL since upgraded to 7.2
On 2022-12-11, Stuart Henderson wrote: > On 2022-12-10, Alceu Rodrigues de Freitas Junior > wrote: >> If I read correctly, the Mikrotik is using an SSLv3 certificate, which I >> guess shouldn't be in use anymore. > > There's no such thing as "an SSLv3 certificate", they are all just X.509 > certs. The sslv3 refers to the type of alert, sslv3 alerts are still > used in TLS; SSLv3 itself hasn't been supported for years. > > It doesn't necessarily use a certificate anyway, it may well be using > ADH for this. Federico, do you have a cert configured for the api-ssl > service on the routeros device, in "/ip service print"? > >> Em 10/12/2022 17:01, Federico Giannici escreveu: >>> Since I upgraded from OpenBSD 7.1 to 7.2 (amd64) I'm no longer able to >>> use IO::Socket::SSL perl library to connect to some devices (Mikrotik >>> routers, via their API). >>> >>> This is the only debug info I was able to obtain: >>> >>> DEBUG: .../IO/Socket/SSL.pm:842: local error: SSL connect attempt failed >>> error:14004410:SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 alert handshake >>> failure > > Maybe try connecting with openssl s_client too? That would help show if > it's a problem specific to IO::Socket::SSL or something more general. > >>> Unfortunately it seems that both perl functions >>> Net::SSLeay::set_security_level() and >>> Net::SSLeay::CTX_set_security_level() don't work. I get the following >>> error. Maybe they are not implemented in our version of Net::SSLeay perl >>> library? > > The security level stuff was only recently added to libressl, it is still > hidden behind #ifndef for libressl in p5-Net-SSLeay. I think you can set > it in the ciphers string though, if it is ADH maybe you need something like > "ADH:ALL:@SECLEVEL=0" (though in that case you would probably be better > advised to generate and use certificates instead). > Also maybe if you show the code you're running it might be easier to make suggestions. -- Please keep replies on the mailing list.
Re: Problems with IO::Socket::SSL since upgraded to 7.2
On 2022-12-10, Alceu Rodrigues de Freitas Junior wrote: > If I read correctly, the Mikrotik is using an SSLv3 certificate, which I > guess shouldn't be in use anymore. There's no such thing as "an SSLv3 certificate", they are all just X.509 certs. The sslv3 refers to the type of alert, sslv3 alerts are still used in TLS; SSLv3 itself hasn't been supported for years. It doesn't necessarily use a certificate anyway, it may well be using ADH for this. Federico, do you have a cert configured for the api-ssl service on the routeros device, in "/ip service print"? > Em 10/12/2022 17:01, Federico Giannici escreveu: >> Since I upgraded from OpenBSD 7.1 to 7.2 (amd64) I'm no longer able to >> use IO::Socket::SSL perl library to connect to some devices (Mikrotik >> routers, via their API). >> >> This is the only debug info I was able to obtain: >> >> DEBUG: .../IO/Socket/SSL.pm:842: local error: SSL connect attempt failed >> error:14004410:SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 alert handshake >> failure Maybe try connecting with openssl s_client too? That would help show if it's a problem specific to IO::Socket::SSL or something more general. >> Unfortunately it seems that both perl functions >> Net::SSLeay::set_security_level() and >> Net::SSLeay::CTX_set_security_level() don't work. I get the following >> error. Maybe they are not implemented in our version of Net::SSLeay perl >> library? The security level stuff was only recently added to libressl, it is still hidden behind #ifndef for libressl in p5-Net-SSLeay. I think you can set it in the ciphers string though, if it is ADH maybe you need something like "ADH:ALL:@SECLEVEL=0" (though in that case you would probably be better advised to generate and use certificates instead). -- Please keep replies on the mailing list.
