Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

[Nan ZoE]

We conducted experiments following the methodology of rop-benchmark
 on both *OpenBSD 6.5* and *OpenBSD
7.3* program testsuites. We injected a simple stack overflow vulnerability
into each program set in these experiments. We attempted to construct an
ROP payload calling *execve("/bin/sh", 0, 0)* using the Gadget collection
from the programs. We validated its correctness by exploiting the
vulnerability. We required the ROP payload to first write the *"/bin/sh"*
string to memory, then sequentially set the *rdi, rsi, rdx,* and *rax *values,
and finally make the *syscall*.


Additionally, the programs from *OpenBSD 6.2* were sourced from
rop-benchmark, while the programs from *OpenBSD 6.5* and *OpenBSD 7.3* were
obtained by installing their respective iso
, and
extracting all executable programs from the systems as our test suites.
These programs can be found on this GitHub repository
, and
we also provided some examples of successfully generated ROP payloads there.


We counted the number of programs in the test set for which we could
successfully execute *execve("/bin/sh", 0, 0)*. The experimental results
showed that the success rate in OpenBSD 6.2, without ROP mitigation
mechanisms, was 96.55%. However, with ROP mitigation mechanisms in OpenBSD
6.5 and 7.3, the success rate decreased to *79.58%* and *50.75%*,
respectively. This indicates the effectiveness of the ROP mitigation
mechanisms implemented in OpenBSD. However, we found that even with these
mitigation measures in place, many Gadgets can still be used. I provided a
detailed analysis in the previous email and some suggestions. For example,
1) reducing Gadgets like pop xxx; ret; clearing registers before function
returns . 2) Transforming the
bytecode (`\xcb`) corresponding to some `retf` instructions to reduce their
frequency in the programs. You can refer to our generated ROP payloads
,
where you will find many ROPs using Gadgets ending with `retf`, as they are
indeed very useful (for rop example in OpenBSD 7.3

).


Best regards,

ZoE

 于2023年10月10日周二 06:26写道：

> Can you show how you arrived at these results? The more detailed the
> better.
>
> Perhaps this should be its own blog post somewhere as well.
>
> I can't speak to the suggested experiments other than to say that having a
> wider audience may be of help.
>
>
>
>
>
>
> Sent: Saturday, October 07, 2023 at 8:13 PM
> From: "Nan ZoE" 
> To: misc@openbsd.org
> Subject: Re: ROP Exploitation in openbsd-64 Programs After Removing ROP
> Gadgets
> Hello,
>
> Thank you very much for all your suggestions first. After our last
> discussion, I conducted some additional experiments and gained a more
> detailed understanding of the ROP mitigation mechanisms implemented during
> the compilation phase of these programs. *I aimed to identify any
> shortcomings in these mitigation mechanisms and attempt to improve them*. I
> want to continue our in-depth discussion regarding these mitigation
> mechanisms.
>
> Firstly, we have observed that OpenBSD is dedicated to reducing the number
> of effective Gadgets during the compilation phase while resisting ROP
> attacks by increasing the complexity of Gadgets. This is a highly
> meaningful and practical approach to ROP defense, as it does not incur the
> significant performance overhead that techniques like CFI (Control Flow
> Integrity) do. Measures like these can be deployed in various application
> scenarios, *as they could be applied to programs in IoT devices or network
> equipment *(such as firewalls). Based on my knowledge, many vulnerabilities
> still exist in these targets, and ROP attack techniques remain the
> preferred choice for attackers during exploitation. *These devices often
> prioritize rapid response and tend to weaken their security defenses;*
> therefore, adding such mitigation measures during the compilation phase
> could significantly enhance their security.
>
> Given that our analysis focuses on ROP attack mitigation measures
> implemented during the compilation phase, our primary evaluation method
> revolves around assessing how ROP attacks can still be executed using only
> Gadgets when these measures are enabled. We conducted experiments where we
> attempted to search for and chain Gadgets within programs to construct ROP
> payloads that achieve the execution of '*execve("/bin/sh", 0, 0)*'. This
> evaluation encompasses two aspects: first, the arbitrary memory-write
> capability of the Gadget set (initially setting memory values to
> *'/bin/sh'*),
> and second, the capability to set the values of the key registers *rdi,
> rsi, rdx*, and *rax *(for setting* rdi, 

Re: Use of fw_update to bootstrap OBSD

[Andrew Hewus Fresh]

On Sun, Oct 08, 2023 at 02:36:16PM +0200, Thomas wrote:
> Hello,
> 
> I am installing OpenBSD on an old xps13 9380. The WiFi is not supported and 
> so I am using a usb dongle for which I need the athn-firmware. I get it to 
> work and now wanting to prep a USB disk with all necessary firmware. I'm 
> following the FAQ#4 on the website (I suppose it works with more firmware 
> than just the WiFi).
> 
> So, now to my question. Using fw_update -F to the current dir does download 
> all firmware (5 files) and SHA256.sig. However, the file SHA256.sig does not 
> include the signature, using signify like so: 
> 
> signify -Cp /etc/signify/openbsd-73-fw.pub -x SHA256.sig *
> 
> Fails with message: invalid comment in SHA256.sig; must start with 'untrusted 
> comment: '
> 
> Downloading the SHA256.sig from firmware.openbsd.org/firmware/7.3/SHA256.sig 
> which includes the signature does work.
> 
> Is it that normal behaviour? Since the firmware.openbsd.org site is not 
> HTTPS, and that, at least for me, fw_update does not download signed 
> SHA256.sig, would it not be possible to download unintended files?

fw_update does download and verify the signature on the SHA256.sig,
however it does then overwrite the one with the signature with one
without the signature.  Normally once it's verified we trust the
location of the files and so we don't need to verify the signature
again, but in the download case that may not be true (even if we trust
the user when installing from a local directory and don't require a
signed SHA256 file).

https://github.com/openbsd/src/blob/master/usr.sbin/fw_update/fw_update.sh#L183-L185


> Thanks in advance,

Thanks for noticing.  I'll look at how best to adjust that when I have
time to look at fw_update again.

Re: relayd ssl termination advice

[Courtney]

Maybe I am wrong, but I thought that relayd was not capable of doing
TLS pass through? That would be preferable if it is possible.

Courtney


On 10/9/23 00:42, Kapetanakis Giannis wrote:

On 08/10/2023 04:00, Courtney wrote:

Ultimately, I want to serve a handful of services on 80/443 that are
easily accessible internally and externally, and I don't want to have
unencrypted traffic between relayd and my server for the services that
are passing sessions and such.


Then don't terminate the connection on relayd. Use redirect instead of a relay 
and terminate on the web server itself.

It will also be a little faster since the router/relayd will only route/pass 
the packets to the appropriate backend server.

For internal traffic you have to use appropriate DNS (local IP) and maybe a 
different certificate.

G

Re: [solved] syslogd in 7.4 no longer likes self signed certificates for TLS remote logging

[Noth]

Ok I solved it. Two issues:

1. the ca.crt file differed on various VMs, possibly due to bitrot

2. the -C option for syslogd to use the ca.crt as distributed to all VMs 
now (wasn't the case as I would append it's content to /etc/ssl/cert.pem 
and that was sufficient up till now) allows for normal logging over TLS 
once again. Thanks Stuart for the suggestion on that.


 Not sure why it had to break on moving 7.4 but at least it's working 
again.


Cheers,

Noth

Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

[fro]

Can you show how you arrived at these results? The more detailed the better.

Perhaps this should be its own blog post somewhere as well.

I can't speak to the suggested experiments other than to say that having a 
wider audience may be of help.


 
 
 

Sent: Saturday, October 07, 2023 at 8:13 PM
From: "Nan ZoE" 
To: misc@openbsd.org
Subject: Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets
Hello,

Thank you very much for all your suggestions first. After our last
discussion, I conducted some additional experiments and gained a more
detailed understanding of the ROP mitigation mechanisms implemented during
the compilation phase of these programs. *I aimed to identify any
shortcomings in these mitigation mechanisms and attempt to improve them*. I
want to continue our in-depth discussion regarding these mitigation
mechanisms.

Firstly, we have observed that OpenBSD is dedicated to reducing the number
of effective Gadgets during the compilation phase while resisting ROP
attacks by increasing the complexity of Gadgets. This is a highly
meaningful and practical approach to ROP defense, as it does not incur the
significant performance overhead that techniques like CFI (Control Flow
Integrity) do. Measures like these can be deployed in various application
scenarios, *as they could be applied to programs in IoT devices or network
equipment *(such as firewalls). Based on my knowledge, many vulnerabilities
still exist in these targets, and ROP attack techniques remain the
preferred choice for attackers during exploitation. *These devices often
prioritize rapid response and tend to weaken their security defenses;*
therefore, adding such mitigation measures during the compilation phase
could significantly enhance their security.

Given that our analysis focuses on ROP attack mitigation measures
implemented during the compilation phase, our primary evaluation method
revolves around assessing how ROP attacks can still be executed using only
Gadgets when these measures are enabled. We conducted experiments where we
attempted to search for and chain Gadgets within programs to construct ROP
payloads that achieve the execution of '*execve("/bin/sh", 0, 0)*'. This
evaluation encompasses two aspects: first, the arbitrary memory-write
capability of the Gadget set (initially setting memory values to *'/bin/sh'*),
and second, the capability to set the values of the key registers *rdi,
rsi, rdx*, and *rax *(for setting* rdi, rsi,* and *rdx *as arguments and *rax
*as the system call number). We conducted experiments on OpenBSD 6.2,
OpenBSD 6.5, and OpenBSD 7.3, extracting the minimal program set for each
version. In *OpenBSD 6.2*, out of 87 programs, we successfully generated
ROP for 84 programs, achieving a success rate of *96.55%*. In *OpenBSD 6.5*,
out of 240 programs, we successfully generated ROP for 191 programs, with a
success rate of *79.58%*. In *OpenBSD 7.3,* out of 264 programs, we only
managed to generate ROP for 134 programs, with a success rate of *50.75%*.
We also manually analyzed the reasons for failure to generate each
program's ROP. In most cases, the inability to control specific register
values led to failures. This was due to a limited number of relevant
Gadgets and their complexity. The range of controllable register values was
restricted. It's worth mentioning that, naturally, if the attack
requirements were lowered, such as requiring control over fewer registers,
it might lead to a higher success rate among the programs.

Based on the experimental data we have gathered, it is evident that
OpenBSD's ROP mitigation measures continually strengthen with each
iteration. They have reduced the number of Gadgets within programs and
increased the complexity of using these Gadgets. The decrease in success
rates is the most compelling evidence of this improvement.

Subsequently, we analyzed the reasons for successfully generating ROP in
some programs, which can be summarized in four key points:

1. While many 'ret'-ending Gadgets have been removed, many 'call' and
'jmp'-ending Gadgets remain usable. These Gadgets allow the storage of jump
addresses in both registers and memory.
2. Despite a reduction in Gadgets for data transfer through 'mov'
instructions, numerous Gadgets still feature arithmetic operations. They
rely on leaked register or memory values to assist in setting target
values, often involving straightforward calculations. (When you have
complete control over the value of a register, it can act like a chain
reaction, assisting in controlling more registers.)
3. Gadgets that involve memory read/write operations are handy, albeit
demanding greater control over multiple register values. Once arbitrary
memory reads or writes are achieved, they can lead to chain reactions,
facilitating control over additional registers or memory values.
4. Conditional branch Gadgets can also be utilized.
5. Additionally, some specific bytecodes employ unique exploitation
techniques, such as 'retf,' 

Re: OT: Paid Email Provider Options

[Kevin]

hostinger.com has hosting plans that include email.

Just forego the hosting part and use their system for email.

Super inexpensive AFAIK they meet the rest of your requirements.

On Mon, Oct 9, 2023 at 11:24 AM Kevin Williams  wrote:
>
> I registered a new domain and I am looking for an email provider for it.
>
> I am happy with k9w.org hosted at fastmail.com and am not looking to change 
> for that domain at this time.
>
> I heard good things about pobox.com, gandi.net, and protonmail. But I want 
> something else.
>
> pobox.com is owned by fastmail. I like fastmail. But I want an entirely 
> separate vendor for this second domain.
>
> I like gandi.net's email options. But they require hosting the domain name 
> with them to use email services. I want to be able to use any registrar to 
> shop the best rates. I don't know if Gandi supports hosting the DNS for a 
> domain and keep its registration elsewhere (registrar versus DNS host).
>
> Protonmail requires use of their own email bridge in order to use third-party 
> email clients, such as Thunderbird and Mutt. Their bridge does not run on 
> OpenBSD.
>
> Also, I want a service that supports at least 100 email aliases so I can use 
> a unique address for every service, such as monopr...@mydomainname.com.
>
> And yes, I know OpenBSD has OpenSMTPD and I could host my own email on any of 
> the VPS'es I have, point the DNS records at a mail spooler service (pobox.com 
> offers this type of forwarding), and thus outsource most of the spam 
> mitigation that way. But I'm still not quite ready to devote the ongoing 
> maintenance time to hosting my own email just yet.
>
> I also don't want to park my domain at any of the tech giants who, advertise, 
> and mine and sell my personal data for profit. (Occasional up-selling of 
> their own services is reasonable.)
>
> I'm looking for a paid email provider that has the following:
> - I can pay them with my money. They don't advertise to me at all about 
> third-party services. They don't sell my info to third parties.
> - I can register my domain anywhere, even if they require I host the DNS with 
> them.
> - I can access it over imap or imaps or another protocol supported by mutt on 
> OpenBSD.
> - Offers at least 100 email aliases, ideally infinite like Gandi.
> - I don't have to run my own mail server.
>
> What suggestions do you all have?
>
> Feel free to reply on or off list.

Re: rdiff-backup remotely

[Daniele B.]

Just to let you know that after retried many backup solutions to solve
the quiz of the making of local backups with a remote machine has file source,
I turned again to Duplicity to produce that delta file that later on I can 
download
to keep updated my local server backup.

-- Daniele Bonini

Re: syslogd in 7.4 no longer likes self signed certificates for TLS remote logging

[Noth]

Hi Stuart,

On 09/10/2023 23:01, Stuart Henderson wrote:

any chance you previously had added certs to /etc/ssl/cert.pem but lost
that when upgrading?

I always readd the ca.crt used to sign the client certs to 
/etc/ssl/cert.pem and distribute the file at upgrade via siteXX.tgz

It's hard to tell the exact cause of your problem since you do not provice 
crucial
data such as any error messages that would appear in a log somewhere.

if there's nothing useful from syslogd, try connecting with nc -vvc
on the relevant machines too. (there was no relevant change to syslogd
since 7.3. there were changes to the various TLS libs but they should
affect nc as well and errors maybe easier to see there).


There is stuff from syslog (my other post took ages to reach the mailing 
list:


on the server:

Oct  9 23:09:30 loghost syslogd[96442]: tls logger "192.168.0.14:35359" 
connection error: handshake failed: error:14039418:SSL 
routines:ACCEPT_SR_CERT_VRFY:tlsv1 alert unknown ca


on the client:

Oct  9 23:09:02 builder syslogd[71166]: loghost 
"@tls4://loghost.domain.local" connection error: certificate 
verification failed: self signed certificate in certificate chain


# nc -vvc loghost.domain.local 6514
Connection to loghost.domain.local (192.168.0.30) 6514 port 
[tcp/syslog-tls] succeeded!
nc: tls handshake failed (certificate verification failed: self signed 
certificate in certificate chain)



We also do not know much about your configuration or what requirements the setup
is supposed to fill. But sure, in quite a number of situations auto-reneweing
Let's Encrypt certificates would be a serviceable solution.

using self-signed certs and requiring a specific cert (via syslogd's
-C option) is certainly a valid configuration too.

I'm going to give -C a go, it might be easier than adding the cert to 
/etc/ssl/cert.pem


Thanks for the suggestions  and confirming syslogd hadn't changed, maybe 
it's the TLS stuff. I need to check the hashes for /etc/ssl/ca.crt as well.


Cheers,

Noth

Re: syslogd in 7.4 no longer likes self signed certificates for TLS remote logging

[Stuart Henderson]

On 2023-10-09, Peter N. M. Hansteen  wrote:
> On Mon, Oct 09, 2023 at 06:42:02PM +0200, Noth wrote:
>> 
>>   I upgraded to 7.4 via CVS on my VMs but not my routers (yet). The 7.3
>> routers are still able to connect via TLS but the 7.4 VMs can't as they
>> don't like the self signed certs. It'd be nice if this was in the
>> upgrade74.html with some explanation of why this changed.
>
> Actually, if you built from source from a recent -current (HEAD) checkout,
> what you got was just that: something that is close to what will be 
> 7.4-release,
> (a matter of weeks if not days), but not actually 7.4-release or -stable.

cvs head is beyond 7.4.

the tree has been tagged with OPENBSD_7_4_BASE but as usual it may still
be re-tagged before release day.

>>   Is my path to getting all this working again the way it was to use Let's
>> Encrypt certificates?

any chance you previously had added certs to /etc/ssl/cert.pem but lost
that when upgrading?

> It's hard to tell the exact cause of your problem since you do not provice 
> crucial
> data such as any error messages that would appear in a log somewhere.

if there's nothing useful from syslogd, try connecting with nc -vvc
on the relevant machines too. (there was no relevant change to syslogd
since 7.3. there were changes to the various TLS libs but they should
affect nc as well and errors maybe easier to see there).

> We also do not know much about your configuration or what requirements the 
> setup
> is supposed to fill. But sure, in quite a number of situations auto-reneweing
> Let's Encrypt certificates would be a serviceable solution.

using self-signed certs and requiring a specific cert (via syslogd's
-C option) is certainly a valid configuration too.


-- 
Please keep replies on the mailing list.

Re: syslogd in 7.4 no longer likes self signed certificates for TLS remote logging

[Noth]

Hi

On 09/10/2023 19:59, Peter N. M. Hansteen wrote:

You are aware that OpenBSD 7.4 has not been released yet, right?

Of course.


On Mon, Oct 09, 2023 at 06:42:02PM +0200, Noth wrote:

   This wasn't covered in http://www.openbsd.org/plus74.html . I have a setup
where various OpenBSD instances log via TLS to a central logger, using self
signed certificates I generated locally (10 year validity). Both the server
and the clients verify each other using the -c & -s options for syslogd on
the clients and -K for the server.

   I upgraded to 7.4 via CVS on my VMs but not my routers (yet). The 7.3
routers are still able to connect via TLS but the 7.4 VMs can't as they
don't like the self signed certs. It'd be nice if this was in the
upgrade74.html with some explanation of why this changed.

Actually, if you built from source from a recent -current (HEAD) checkout,
what you got was just that: something that is close to what will be 7.4-release,
(a matter of weeks if not days), but not actually 7.4-release or -stable.
I downloaded 7.4 from CVS last Wednesday and built it. I don't use 
-current. I am aware it's not officially released yet but it's close to 
being.

   Is my path to getting all this working again the way it was to use Let's
Encrypt certificates?

It's hard to tell the exact cause of your problem since you do not provice 
crucial
data such as any error messages that would appear in a log somewhere.

We also do not know much about your configuration or what requirements the setup
is supposed to fill. But sure, in quite a number of situations auto-reneweing
Let's Encrypt certificates would be a serviceable solution.

- Peter


client side /etc/rc.conf.local snippet:

syslogd_flags=-c /etc/ssl/buildhost.domain.local.crt -k 
/etc/ssl/private/buildhost.domain.local.key


client side /etc/syslog.conf snippet:

*.notice;auth,authpriv,cron,ftp,kern,lpr,mail,user.none 
@tls://loghost.domain.local

auth,daemon,syslog,user.info;authpriv,kern.debug @tls://loghost.domain.local

Error message for client is: Oct  9 21:30:50 buildhost syslogd[42102]: 
loghost "@tls://loghost.domain.local" connection error: certificate 
verification failed: self signed certificate in certificate chain


server side rc.conf.local snippet:

syslogd_flags=-u -T 192.168.50.30:514 -S loghost.domain.local -S 
192.168.0.30 -K /etc/ssl/ca.crt



Error server side is: Oct  9 21:31:20 loghost syslogd[39364]: tls logger 
"192.168.0.14:43535" connection error: handshake failed: 
error:14039418:SSL routines:ACCEPT_SR_CERT_VRFY:tlsv1 alert unknown ca


I hope this illustrates it a bit better.

Cheers,

Noth

Re: Smtpd is not adding message-id

[Todd C . Miller]

On Mon, 09 Oct 2023 19:32:50 +0200, Nicolas Goy wrote:

> I am hitting this issue with some go based process that send emails:
>
> https://github.com/OpenSMTPD/OpenSMTPD/issues/1068
>
> Basically the client is not putting any Message-Id header and smtpd is 
> not adding it when sending the email.
>
> Do you have an idea how to work around it? Or do I need to patch and 
> recompile smtpd?

I just committed the fix but I don't think there is a workaround.
You will need to patch and recompile smtpd.

 - todd

Re: debugging "invalid argument" errors when loading elf files

[Philip Guenther]

On Mon, Oct 9, 2023 at 11:21 AM Lorenz (xha)  wrote:

> hi misc@,
>
> i'm currently porting the hare programming language to openbsd and i am
> having quite a few problems trying to use a linker script. i am always
> getting a "/bin/ksh: .bin/hare: Invalid argument" error.
>
> so far i tried a lot of stuff like comparing a working version without a
> linker script, looking if any of the programm headers are missing, etc.
>

So you have a working binary (w/o linker script) and a not-working binary
(w/linker script) and you've even done the comparison of the program
headers of the two...and you're not going to show those but rather ask
what, in general, could be wrong?  Okay.

Lacking the specifics of those differences (which you've already
identified), the general advice is this:

Read /usr/src/sys/kern/*exec* and review the logic around the 10
occurrences of EINVAL in that code.  Presumably the differences you
identified will point to one or more of them


Philip Guenther

Smtpd is not adding message-id

[Nicolas Goy]

Hello,

I am hitting this issue with some go based process that send emails:

https://github.com/OpenSMTPD/OpenSMTPD/issues/1068

Basically the client is not putting any Message-Id header and smtpd is 
not adding it when sending the email.


Do you have an idea how to work around it? Or do I need to patch and 
recompile smtpd?


Regards

--
Nicolas Goy
Engineer & Developer

https://www.kuon.ch
https://www.goyman.com

OT: Paid Email Provider Options

[Kevin Williams]

I registered a new domain and I am looking for an email provider for it.

I am happy with k9w.org hosted at fastmail.com and am not looking to change for 
that domain at this time.

I heard good things about pobox.com, gandi.net, and protonmail. But I want 
something else.

pobox.com is owned by fastmail. I like fastmail. But I want an entirely 
separate vendor for this second domain.

I like gandi.net's email options. But they require hosting the domain name with 
them to use email services. I want to be able to use any registrar to shop the 
best rates. I don't know if Gandi supports hosting the DNS for a domain and 
keep its registration elsewhere (registrar versus DNS host).

Protonmail requires use of their own email bridge in order to use third-party 
email clients, such as Thunderbird and Mutt. Their bridge does not run on 
OpenBSD.

Also, I want a service that supports at least 100 email aliases so I can use a 
unique address for every service, such as monopr...@mydomainname.com.

And yes, I know OpenBSD has OpenSMTPD and I could host my own email on any of 
the VPS'es I have, point the DNS records at a mail spooler service (pobox.com 
offers this type of forwarding), and thus outsource most of the spam mitigation 
that way. But I'm still not quite ready to devote the ongoing maintenance time 
to hosting my own email just yet.

I also don't want to park my domain at any of the tech giants who, advertise, 
and mine and sell my personal data for profit. (Occasional up-selling of their 
own services is reasonable.)

I'm looking for a paid email provider that has the following:
- I can pay them with my money. They don't advertise to me at all about 
third-party services. They don't sell my info to third parties.
- I can register my domain anywhere, even if they require I host the DNS with 
them.
- I can access it over imap or imaps or another protocol supported by mutt on 
OpenBSD.
- Offers at least 100 email aliases, ideally infinite like Gandi.
- I don't have to run my own mail server.

What suggestions do you all have?

Feel free to reply on or off list.

debugging "invalid argument" errors when loading elf files

[Lorenz (xha)]

hi misc@,

i'm currently porting the hare programming language to openbsd and i am
having quite a few problems trying to use a linker script. i am always
getting a "/bin/ksh: .bin/hare: Invalid argument" error.

so far i tried a lot of stuff like comparing a working version without a
linker script, looking if any of the programm headers are missing, etc.

i am not missing the .note.openbsd.ident section.

is it possible to debug such errors to find out what is missing? i just
need an error message. :D

(it would be very kind if someone could send me a working, minimal
linker script for a simple dynamic C programm)

- lorenz

Re: syslogd in 7.4 no longer likes self signed certificates for TLS remote logging

[Peter N. M. Hansteen]

You are aware that OpenBSD 7.4 has not been released yet, right?

On Mon, Oct 09, 2023 at 06:42:02PM +0200, Noth wrote:
> 
>   This wasn't covered in http://www.openbsd.org/plus74.html . I have a setup
> where various OpenBSD instances log via TLS to a central logger, using self
> signed certificates I generated locally (10 year validity). Both the server
> and the clients verify each other using the -c & -s options for syslogd on
> the clients and -K for the server.
> 
>   I upgraded to 7.4 via CVS on my VMs but not my routers (yet). The 7.3
> routers are still able to connect via TLS but the 7.4 VMs can't as they
> don't like the self signed certs. It'd be nice if this was in the
> upgrade74.html with some explanation of why this changed.

Actually, if you built from source from a recent -current (HEAD) checkout,
what you got was just that: something that is close to what will be 7.4-release,
(a matter of weeks if not days), but not actually 7.4-release or -stable.

>   Is my path to getting all this working again the way it was to use Let's
> Encrypt certificates?

It's hard to tell the exact cause of your problem since you do not provice 
crucial
data such as any error messages that would appear in a log somewhere.

We also do not know much about your configuration or what requirements the setup
is supposed to fill. But sure, in quite a number of situations auto-reneweing
Let's Encrypt certificates would be a serviceable solution.

- Peter

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

syslogd in 7.4 no longer likes self signed certificates for TLS remote logging

[Noth]

Hello,

  This wasn't covered in http://www.openbsd.org/plus74.html . I have a 
setup where various OpenBSD instances log via TLS to a central logger, 
using self signed certificates I generated locally (10 year validity). 
Both the server and the clients verify each other using the -c & -s 
options for syslogd on the clients and -K for the server.


  I upgraded to 7.4 via CVS on my VMs but not my routers (yet). The 7.3 
routers are still able to connect via TLS but the 7.4 VMs can't as they 
don't like the self signed certs. It'd be nice if this was in the 
upgrade74.html with some explanation of why this changed.


  Is my path to getting all this working again the way it was to use 
Let's Encrypt certificates?


Cheers,

Noth

Re: relayd ssl termination advice

[Kapetanakis Giannis]

On 08/10/2023 04:00, Courtney wrote:
> Ultimately, I want to serve a handful of services on 80/443 that are
> easily accessible internally and externally, and I don't want to have
> unencrypted traffic between relayd and my server for the services that
> are passing sessions and such.


Then don't terminate the connection on relayd. Use redirect instead of a relay 
and terminate on the web server itself.

It will also be a little faster since the router/relayd will only route/pass 
the packets to the appropriate backend server.

For internal traffic you have to use appropriate DNS (local IP) and maybe a 
different certificate.

G